where to package helper java classes

Discussions

EJB design: where to package helper java classes

  1. where to package helper java classes (4 messages)

    Hi everybody,
    I deployed a session EJB on the JBoss server.
    My EJB uses helper java classes to do its job.
    I would like to know if there is a benefit to bundle these helper classes in the EJB jar?
    What is the best technique in terms of performence and container management? Package the helper classes in the same EJB jar or in a separate jar?
    Thank you very much.
    Stan.

    Threaded Messages (4)

  2. where to package helper java classes[ Go to top ]

    Hi everybody,

    > I deployed a session EJB on the JBoss server.
    > My EJB uses helper java classes to do its job.
    > I would like to know if there is a benefit to bundle these helper classes in the EJB jar?
    > What is the best technique in terms of performence and container management? Package the helper classes in the same EJB jar or in a separate jar?
    > Thank you very much.
    > Stan.

    If you deploy your application as EAR file, you could package helper classes as jar file at the root level of EAR file and in the manifest file of ejb-jar refer to this jar. (This is all done by extension mechanism available with JDK1.3 onwards). The advantage is that same helper classes can be utilized by other ejb jar files or any other component.
  3. where to package helper java classes[ Go to top ]

    Hi Hari,
    thank you very much.
    I understood your statement.
    But what if I do not use a EAR file. My EJB will be deployed on different remote
    servers.
    Should I bundle my helper classes in each EJB jar or bundle them in a common jar
    available in the classpath of each remote server??
    Which is the best option in your opinion??

    Thank you.
    Stan.
  4. EJB Packaging[ Go to top ]

    You really should consider packaging the EJB-jar into an EAR file: there are no side-effects, it is very easy to do, and you might then be able to package the jar-library within the same EAR. This approach, however, makes you responsible for managing different jar-library versions that can exists on different deployed applications (there is no conflict between them because each application has its own classloader, but it is a *managent* problem).

    Putting the jar-library at the server classpath might work too, but it has indeed some potential problems:

      . You can only upgrade a jar-library by restarting the app server;
      . You need to be very careful when delivering a new version (you may break ALL aplications that use this library);
      . But the worst problem is this: there are some libraries that CAN NOT be deployed at the server classpath. Some libraries, for an example, may have singletons that assume they live within the context of an isolated web application (ex: Struts), therefore leading to unexpected results when deployed at server level.

    If, like me, you like to have only one deployed version of a jar-library (i.e. you prefer to be careful when mantaining a single jar file instead of managing different versions of this file within different apps), there is a 3rd alternative. You can deploy "safe" jar files at the server level (server classpath or server "lib/ext"), AND you can have a library dir containing all JAR files that cannot reside at server level. These latter can be referenced (by absolute path) by the manifest file of every EAR or WAR the needs them.

    You will find out that in practice the manifest file has a very annoying syntax, and that each app server will require a slightly different manifest (ex: in JBoss each classpath entry requires the "file:/" prefix, in WAS you must not use the "file:/" prefix and in WLS you can only use relative paths like "../../../mylib.jar"). But after you get used to it all things work quite well.
  5. EJB Packaging[ Go to top ]

    Hi Andre,
    Thank you very much.
    You are very clear so I'll use your suggestions.
    Thank you.
    Stan.