-
1. Re: Shared classpath within an EAR?
JBoss classloading can be tricky. As a rough intro:
Everything in an EAR sees everything else, with the exception of the WAR file. Nobody outside of the WAR sees what is inside the WAR. (there is a configuration option to change this)
Classes are shared between EAR files, which can lead to some nasty problems if you aren't aware of what is happening. You can restrict the sharing of classes between EARs. It's fairly simple to do, and I personally recommend doing that for all your applications. It is almost always what you want to do.
For more in depth info: http://wiki.jboss.org/wiki/Wiki.jsp?page=ClassLoadingConfiguration -
2. Re: Shared classpath within an EAR?
Norman, thanks for the response. A couple follow-up questions for you.
I've been reading up on classpaths in Java EE and it seems you can configure classpaths by putting information into the MANIFEST.MF file. However, it seems like in JBoss you don't really "need" to do it, because classpaths are always magically found regardless.
Should I put classpath information into the MANIFEST.MF? Or is it not necessary and just redundant?
Secondly, I tried putting all the libraries for my EAR into my EJB JAR's lib folder...however, my WAR started complaining that it couldn't find one of the .tld files, even though it was there within the JAR...is there an exception to what you said with tag libraries?
What are all the options JBoss has for configuring classpaths? Where are all the places I have the option of putting it within the EAR? Some work better than others in JBoss... -
3. Re: Shared classpath within an EAR?
Also, while one of the options is to place it directly underneath the EAR and declare it in application.xml as a java module, that could get really messy really quickly if you have many JAR libs...
Is there a way to declare a directory containing libs as being visible to the entire EAR's classpath? -
4. Re: Shared classpath within an EAR?
You really should not use the java module approach. There are other alternatives. EE5 includes mechanism to load thirdparty jars from a centralized location.
In J2EE 1.4 you can declare a libs directory, place your 3rd party jars in them and list each one explicitly in the MANIFEST.MF file of your application components
EAR
-->lib
-->jar1
-->jar2
ejb-module.jar
-->META-INF
-->MANIFEST.MF
(Class-Path: lib/jar1.jar, lib/jar2.jar
Note, regular scoping rules apply in that if you are using an isolated CL with Java2ParentDelegation turned off, this will force the load from the lib directory. If not, and a class exists in a higher class loader, this one will be chosen. -
5. Re: Shared classpath within an EAR?
Thanks for that answer, I've got a few more questions on this topic:
1) In the case with the EAR/lib directory containing JARs that you mentioned, wouldn't an archive within the EAR still look at EAR/lib JARs even with Java2ParentDelegation set to true? Because (based on what I figure from reading the JBoss ClassLoading wikis) the class would first look in its own UCL, then would look at the EAR's UCL (which would contain the JARs in EAR/lib...is my reasoning not correct here?
2) I read that you can have, in the deploy directory itself, a regular JAR file (i.e. I don't mean EJB-JAR, but a regular JAR containing utility or other classes that you may want on your classpath)...is this really possible?
How would this JAR in the deploy directory fit into the ClassLoader "hierarchy" explained at http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossClassLoadingUseCases?
What would it be visible to?
3) Why should we not use the java module approach? Are there reasons that'd make it difficult to manage (like having to add them all to application.xml) or is it just not the way things are done? -
6. Re: Shared classpath within an EAR?
1) In the case with the EAR/lib directory containing JARs that you mentioned, wouldn't an archive within the EAR still look at EAR/lib JARs even with Java2ParentDelegation set to true?
Yes, and this is quite often the cause of issues. A good example is wanting to use Hibernate/Xalan/Xerces jars that conflict with thirdparty jars that exist in JBoss. One of the major reasons for classloader isolation is when you want to use a different version of jar offered in your application environment.
2) I read that you can have, in the deploy directory itself, a regular JAR file (i.e. I don't mean EJB-JAR, but a regular JAR containing utility or other classes that you may want on your classpath)...is this really possible?
Yes, the classes will be added to the LoaderRepository and a UCL created. However, this can create versioning issues rather quickly. Classic example is a jar file that an EJB and WAR depend on. Simply deploying the jar in a hot deployment environment will not work in this case and both the deployment units (WAR/EJB) would have to be redeployed as well. This can get real messy, real quick no matter how much you may think your build/release process can do to help you manage this.
What would it be visible to?
Everything ;-)
3) Why should we not use the java module approach? Are there reasons that'd make it difficult to manage (like having to add them all to application.xml) or is it just not the way things are done?
Largely because this was a mistaken implementation to begin with and was added prior to the J2EE spec defining an well defined Classloading model for utility jars. Technically the<module> <java>somejar.jar</module> </module>
is for J2EE ApplicationClient deployments and should only be used a such.
There is no guarantee that this approach will not be removed in the furture. In fact, I can pretty much guarantee you that it will be.
While JBoss allows a 'flexible' approach to deployments (and in many ways allows things that it really shouldn't), sometimes this can cause serious deployment/management headachese. Sticking with a standard well know mechanism can often pay dividends in the long run. -
7. Re: Shared classpath within an EAR?
I apologize if I've missed the answer to this question elsewhere, but does JBoss-5.0.0-Beta1 support the JEE 5 /lib directory in the root of ear file?
I have a JEE 5 application that I've been using on glassfish, with shared library jars in the /lib folder of the ear file, but I am unable to deploy this application on JBoss 5... I get a NoClassDefFound exception for each class in the shared library jars (during deployment of EJBs).
I'd just like to know if I still have to do the ear's manifest Class-Path thing...
... And I'd much rather be using JBoss...
Thanks in advance!