I am using JBoss 3.0.1 RC1. I am having a strange problem that seems to indicate that my manifest.mf files are ignored (or incorrectly specified) when deploying my ears. I have two ears that each deploy the same util.jar. Running the first ear gets the correct util.jar classes. Next, running the second ear shows that its util.jar classes are from the first ear!
Here is a description of my two ears that are deployed.
....META-INF/application.xml: modules ejb1.jar, web1.war
.......META-INF/ejb-jar.xml: contains <ejb-client-jar>ejb1_client.jar<ejb-client-jar>
.......META-INF/Manifest.mf: Class-Path: ./library/ejb1_client.jar
............META-INF/Manifest.mf: Class-Path: ./util.jar
....META-INF/application.xml: modules ejb2.jar, web2.jar
........META-INF/ejb-jar.xml: contains <ejb-client-jar>ejb2_client.jar<ejb-client-jar>
........META-INF/Manifest.mf: Class-Path: ./library2/ejb2_client.jar
............META-INF/Manifest.mf: Class-Path: ./util.jar
If I run the cactus tests on app1.ear first, then the classes in util.jar show the class loader as app1.ear/71.app1.ear-contents/library/ejb1_client.jar. Next, I run the a servlet in app2.ear, then the classes in util jar show the previous class loader as ebj1_client.jar. Therfore, the util.jar packaged in my app2.ear is never being used.
Also if I reverse my test order and run app2 and then app1. I see that util.jar from app1.ear is never used.
I would like to keep my two applications independent of each other. Each application using its own version of util.jar. How can I do this?
Any help is greatly appreciated. THANKS!
Hmmmm. I am confused by your ear layout, specifically the inclusion of a folder (library) at the root level containing its own META-INF/Manifest.mf. Is this standard J2EE? I don't think so. I'm no expert, but if you have a reference for this layout, please divulge. If I am correct, I would do the following. The manifest.mf should be in the root level META-INF. Throw out the duplicate ejb_client.jar. You can leave library there containing util.jar. Now there is a bug in JBoss dealing with references in the manifest Class-Path. I fixed this bug. If you get the latest copy of JBoss and look in org.jboss.deployment.MainDeployer.parseManifestLibraries to get latest change.
Thanks for the info!! I will try out the patch and your suggestions.
As for your question, my post is not clear enough. My ears have a library folder. The ejb1_client.jar and ejb2_client.jar contains the manifest files. My references were cobbled together from the J2EE 1.3 spec section 188.8.131.52 and from http://www.jboss.org/online-manual/HTML/ch13s72.html.
However, I must have tried a hundred variations with no luck. I will post again if there is no luck.
I checked out and build the JBoss 3.1.0 alpha. I also changed the ear configuration as you suggested.
Unfortunately, I am still getting the cross-linked ears where the util.jar from app1.ear is used in app2.ear. However, I am getting some errors that lead me to think that the manifest changes are still not working.
First, jetty has errors on startup.
2002-07-29 01:46:04,437 WARN [org.jboss.deployment.MainDeployer] The manifest entry in file:/D:/jboss-current-src/jboss-all/build/output/jboss-3.1.0alpha/server/default/deploy/jbossweb.sar/org.mortbay.jetty.jar references URL file:/D:/jboss-current-src/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/server/default/deploy/jbossweb.sar/org.mortbay.jetty.jar/42.org.mortbay.jetty.jar-contents/javax.servlet.jar which could not be opened, entry ignored
Second, I had to change all my classpath entries to be ../util.jar where I expected either ./util.jar or util.jar.
When I deploy my wars, I get the following errors.
2002-07-29 01:46:22,313 WARN [org.jboss.jetty.JBossWebApplicationContext#/script] bad classpath entry: file:/D:/jboss-current-src/jboss-all/build/output/jboss-3.1.0alpha/server/default/tmp/deploy/server/default/deploy/app1.ear/63.app1.ear-contents/ejb1.jar-contents/../ejb1_client.jar-contents/../util.jar
Given the errors that I am seeing, I suspect there is still some issue with parsing the manifests and/or my deployment.
If you want to have two copies of the same-named class loaded at once, you need to do some extra work. You need to deploy in .ears and you need to include a jboss-app.xml next to your application.xml. The jboss-app.xml needs to specify the loader repository for the .ear: this defines the classloader space. The loader repository name needs to be a valid object name not used by anything else in the system.
Here's a simple jboss-app.xml example:
You can also use this file to deploy jboss-specific deployment units, namely .sar and -service.xml files.
I think we are having trouble communicating. If you want, send me one of your ear and I will unpack it and repack it like I think it should be and send it back to you.
Thanks. I tried your suggestion and now each ear uses its own util.jar.
As a follow on question, I package in the log4j.jar into my ears similar to util.jar. However, I am still getting the JBoss' log4j.jar instead of my ear's local log4j.jar.
Let me be clearer. I followed sgturner's suggestion of adding the jboss-app.xml files to my ear's META-INF directory. Now, my util.jars stay with their own ears.
When JBoss starts up, it first loads things in jboss/lib, then loads things in jboss/server//lib. By the time it loads your ear file, log4j has been already loaded by a class loader that is the parent of any class loader that loads the ear. So, that will never happen
Just for my clarification. It sounds like packaging log4j.jar into my ears is futile because log4j.jar is already loaded by JBoss. My ear cannot load its own version of log4j.jar.
<It sounds like packaging log4j.jar into my ears is futile because log4j.jar is already loaded by JBoss. My ear cannot load its own version of log4j.jar.>
That is correct.
I try to deploy an application ear that comes with log4j in a different version that the one wich is part of jboss 3.0.4. I think i've read extensiveley all the posts including this one.
So, what should i do ? Should I re-pacakge my application specific to jboss because of the use of log4j Vxxx by jboss ? What if my application use a newer version of log4j ?
This must be a recurrent problem, because log4j is widely used by many j2ee applications. I found a little hard to have to deal with it this way, because jboss is using log4j! By the way, what for the other shared libs that are used by jboss ? Same cause, same punishment ?
More generally how Jboss address issues pointed in "classloading problems" chapter of this article : http://www2.theserverside.com/resources/articles/AdvancedClassLoading/article.html (IONA approach).