I have a J2EE design question. This is the scenario in our project:
The reusable business logic will be implemented in stateless session beans. We want to deploy these business logic EJBs separatly to the application server. By doing this we want to be able to add new business logic to the server without interrupting any runing client. We could also easily update an EJB on the server.
Our business logic beans share some service classes. We have packaged these classes into a service JAR.
My question is: what is the best way to deploy these service JAR files? The service JAR files include also a JAR file for the Xerces XML parser.
Do we need to package these service JARs into each business logic component?
I know that some application server have a directory where you can put libraries each running application can access. But what if different application need different versions of an XML parser?
What is the best place for application specific libraries?
Thanks in advance.
There are three ways of doing this:
1) If the appserver provides dynamic loading (JBoss comes to mind), drop the .jar in there.
2) Put the .jar in the JVM classpath (NOT a good idea).
3) Bundle the .jar in an EAR with the EJBs. Yes, this duplicates the .jar in all of your EAR files, but that makes each EAR completely independent and allows for easy hot-deployment.
Hi E. A.!
Thanks for your reply.
Could you please explain your way number 1) ? I think I haven't got the clue yet.
Way 3 could become problematic if the JAR has to be updated. You will have to update all runing EAR files with the new JAR. Is this an elegant solution?
Method #1 depends upon the app server. JBoss is one that (I believe) will dynamically examine a specific directory for classes in .jar files. Not a portable solution.
Method #3 is the one I recommend the most. And, yes, if the JAR file changes, you have to rebuild and redeploy all the EAR files that use it. However, since it's contained in a "hot-deployable" EAR, you just, well, deploy the new one in place of the old one!
A suggestion: if this JAR is being used across a lot of EARs, you had better have a really compelling reason for it and keep it small/simple.
Thanks for your suggestion. We will take method # 3 in our project.
The JAR will contain service classes (i.e. special string operations, or special XML operations). We want to get speed at this operations, so we don't want to convert all to session beans.
Do you have more hints for our scenario?
Thanks in advance.