Discussions

EJB design: EJB Multilanguage

  1. EJB Multilanguage (9 messages)

    Hi all,
    I would like to hear your opinion about this:
    - What is the best way to handle Exception in EJB especially in Multilanguage EJB?

    Situation:
    Servlet -> Stateless Session Beans -> Entity Beans

    If an logical error happens in my stateless SB, I have to catch them in my SB. The problem is, how can I throw an exception with its message, which should depend on the language the user has choosen before?

    Solutions:
    - Using extra parameter in every business methods. So everytime I call my business methods in my stateless SB from my servlet, I have to send the language through this parameter as well. This solution is used by Java PetStore example.
    --> This is bad.

    - Handle all the messages from the exception, which is thrown from the stateless SB, at the servlet layer.
    --> I don't like this, because all the messages have to be managed at the servlet layer.

    Comparison:
    Security context in J2EE allows me to propagate my username and password to my EJB, which I've typed in my servlet before. So I don't need to use extra parameter in each of my business method, which passes my username and password.

    Is there something similar like this for multilanguage EJB?
    --
    ---------------------------------------------------
    Blasius Lofi Dewanto
    ---------------------------------------------------
    OpenUSS - Open University Support System
    http://openuss.sourceforge.net
    ---------------------------------------------------

    Threaded Messages (9)

  2. EJB Multilanguage[ Go to top ]


    It makes sense to handle your exceptions at the Servlet layer and map these to the error messages you want to display to a user in whatever language - this is afterall a presentational responsibility so why not do it in the presentation layer. Also in my experience its never a good idea to take what a developer thinks is a useful exception message and display this to the end user.

    As for passing around context parameters in a local environment you can use java.lang.ThreadLocal variables but i very much doubt if these will be propagated with a remote call.

    Stu
  3. EJB Multilanguage[ Go to top ]

    <quote>
    It makes sense to handle your exceptions at the Servlet layer and map these to the error messages you want to display to a user in whatever language - this is afterall a presentational responsibility so why not do it in the presentation layer. Also in my experience its never a good idea to take what a developer thinks is a useful exception message and display this to the end user.
    </quote>

    This means, I have to create many type of exceptions for my EJBs. And I have to catch each of them in my servlet...

    In a scenario, where I use Servlet <-> Stateless SB <-> EB this could be very tedious... As maybe you can imagine, there are sometimes more than one kind of exceptions in one method of those stateless session beans.

    I also wonder, why PetStore use the language (locale) as a parameter in each methods...

    Any idea?

  4. EJB Multilanguage[ Go to top ]

    <quote>
    Also in my experience its never a good idea to take what a developer thinks is a useful exception message and display this to the end user.
    </quote>

    BTW. the developers also write the servlets... So it does not play any role, whether the messages are written in EJB layer or in Servlet layer, correct?

    Lofi.
  5. EJB Multilanguage[ Go to top ]


    >> BTW. the developers also write the servlets...

    Yeah they do but if i'm writing the servlets and part of that responsibility is to ensure that a clear error message is displayed to the user then i'm not going to rely on the exception messages used by people writing the ejb tier.

    Stu
  6. EJB Multilanguage[ Go to top ]

    We have a similar problem in our project and solve it in the following way:

    - There are only two different exceptions: technical and business logic.
    - Every exceptions has a clear error code.

    That means there are only two different kinds of exceptions must be handled (no big try-catch). Both types of exceptions have a message and an error code. The message is always in english language and is only for logging reasons. The error code is used to make some mapping to the user language.
    We used that way because the administrator is able to read english an is able to understand the meaning of each exception. (Think about something like 'database can not be contacted'. No end user can handle this exception.) The end user only get well defined error messages in the correct language.
    All the end user messages are handled in resource bundles in the presentation tier (servlets). The only thing you have to do is to make a mapping 'error code' -> 'end user message'.

    Hope this will help you.

    Andy
  7. EJB Multilanguage[ Go to top ]

    <quote>
    - There are only two different exceptions: technical and business logic.
    - Every exceptions has a clear error code.
    </quote>

    Great Idea! You should put this into a design pattern for handling exceptions in J2EE architecture.

    Thanks!
    Lofi.
  8. EJB Multilanguage[ Go to top ]


    I've done something similar to this before but was never really that sure about it :

    In a large system how do you ensure that error codes remain unique.

    If you only have two types of exception then you prevent the clients of your component possibly handling them ie some technical exceptions or business exception may be recoverable but how can i handle different types of technical exception without catch them all examining the error code and determining what to do with them. You end up with all your subclasses of technical exception and business exception anyway. Rather than the error code you can then just map end user error messages from the exception class name (therefore ensuring that it is unique).

  9. EJB Multilanguage[ Go to top ]

    How about this:

    Why not create an Exception class whose constructors takes an instance of both TechnicalException and BusinessException.

    When throwing an exception in the EJB tier, pass an error code as the technical exception and a user friendly "businessy" type message as the business exception

       throw new AppException(new TechException("FR055"),
                             new BusinessException("System is currently unavailable. Please try again later."));

    Create an error code supporting document containing all of the technical exceptions (for the administrator).

    This way the servlet layer can handle the exception, and it can output both the technical and business exception. And ... in a larger system you can reuse exceptions.
  10. EJB Multilanguage[ Go to top ]

    If you only have two types of exception then you prevent the clients of your component possibly handling them ie some technical exceptions or business exception may be recoverable but how can i handle different types of technical exception without catch them all examining the error code and determining what to do with them.


    It can be handled by extending TechnicalException and BusinessException, I will encourage the following model:
               ChainableException
           ____________|______________
          | |
    BuisnessException TechnicalException
          | | | |
    MoreSpecificException ...

    So that you can catch only BusinessException and TechnicalException if you don't care about what specific exception it belongs to, or you can capture the MoreSpecificException and do recovery and what so ever...

    The above model is just to show how to organize the exceptions so that different developers can capture exception at different levels to fit their own needs. I am
    actually personally against the idea of differentiate BusinessException and TechnicalException, since they are talking about the same thing and it's so hard to differentiate them in some cases and some are actually both business and technical exception depending on the scenerios. Imagine a Single-Login server which handles all user name / password checking and login session tracking, when a user name and password mismatch with database, an exception will be thrown to client program. So what kind of exception will this be? It could be BusinessException since possibly a Servlet is calling the server and would like to display a user friendly message to the end user. But it could be a system scheduler which is running some batch job and generate the report to a system administrator when the job is done. So in this case the exception should be more technical? Or it is still business since we can treat the amdinistrator as a end user? Or both is all rite, really depends on the client program to decide the nature of the exception?

    I tends to think that the exception itself should not be defined as technical or business related, it should be rather defined in a structure that make sense to the application. Let's say, SecurityException, UserInputException, and etc, or all exception of a application have the common root, say RootException or ChainableException. The strcuture can be application dependent, it can be defined in a way that if you are not interested in details of a particular type of interest, you just need to capture the super class exception, like a UserInputValidationException. If you want to differentiate the exceptions and handle them differently, then capture the subclasses.

    But I do like the idea of Any that each exception has an error code and a description for logging purpose. That's a good idea to cater for the need of both flexible/customizable/internationalized error messages, and loggings. If an chainable exception pattern is used here then it will be even greater.