How To Design an Error Manager Bean?


EJB design: How To Design an Error Manager Bean?

  1. How To Design an Error Manager Bean? (5 messages)

    I'm working on a legacy EJB project. Some of the key components are 'cached' entity beans, though no-one thinks the current implementation is very nice. (Basically, it was written in the early days of EJB by developers learning on the job.)

    I would like some advice on the correct way to implement a service which is a once-only component which starts on first use (or container startup preferably) and can load an XML catalogue of error messages, then sit and wait for requests to translate exceptions.

    The intent is to have ONE of these memory expensive objects only, and to have it available to all beans, all the time.

    How would you design such a thing?

    Threaded Messages (5)

  2. Singleton[ Go to top ]

    I suppose that what you basically want is to implement an EJB singleton, which is not permitted by the EJB spec (you never know how many class loaders there are in your ejb container). The usual way around this is to implement the logger in RMI.

    You might want to check out the following at jGuru:
  3. RMI object?[ Go to top ]

    I was trying to avoid prejudicing anyone towards a solution with my wording,
    but yes, essentially what we have tried to write is a Singleton error catalogue.

    I am not sure what is meant by writing "an RMI object", although obviously I have used RMI before. Could you expand on that solution?

    Our current plan, if we ever have time!, is to go back and rip out the references to the current bean, and replace it with a simple static Map in the base class for all bean implementations. Currently, all error processing is carried out in this class anyway, collecting and forwarding all exceptions (of which we expect many as some "warnings" are modelled this way) and translating them via the 'cached entity bean' (which doesn't actually cache them as it activates and passivates anyway, re-reading the large XML file each time).
  4. Try the simple way[ Go to top ]

    Why not create a remote interface EJB that instanciates its implementation as a static singleton. Just deploy it to one server there should only be one class loader per deployment descriptor even if the spec says different. Though I would try it and trace out creation and make sure only one is created. I am pretty sure this should work in jboss or weblogic. Better if you initialise the static implementation class from server startup. Your base class solution will for sure be duplicated per managed server. Which is ok if you only have one.

    cheers Robert
  5. RMI[ Go to top ]

    In RMI the server creates the instance of the remote object and publishes it in the RMI registry. Remember, this is the business object that is going into the registry, not a factory like a home stub. So clients do direct lookups on the business object itself, which the server can constrain to a singleton.

    A refresher on the basics of RMI can be found at:

    Remember that you are responsible for managing threading in an RMI object.
  6. RMI[ Go to top ]

    Just noticed that the RMI singleton was discussed in the Patterns forum a few days ago: