The tomcat class loader used by default since 4.0.2 does not honor the war manifest classpath, but the ear still does and the wars should pickup these classes. I'll recheck the unit test we have for this.
Thanks in the meantime i'm just loading the jars via the application.xml. One thing I should mention maybe is that the jars i'm loading are jars that are for working with myfaces. I removed the jsf-libs that come with jboss because i use the latest nightly build of myfaces and i didn't want an older jars being loaded. Not sure if that makes any difference.
Actually, the war manifest testcase is working so I would need to see your exact war manifest Class-Path. It does not make sense that the ear and war classpath would be exactly the same since they have different relative locations.
Hi We have the same problem in 4.0.3,
I have the following manifest file and deploying ear.
class-path: ../erxlib/eRxUtilities.jar ../erxlib/IntroducerJAR.jar
It is working fine in 4.0.02.
That is the class-path of the war in the ear or the ear?
here is my directory structure i don't put any jars in the WEB-INF/lib all the jars need by my web apps are held in the ear's lib directory...
myear /lib *common*.jar web1.war web2.war ejb.ejb3 aop.aop /META-INF application.xml MANIFEST.MF
I only ever update the MANIFEST.MF file in my ear project. My build script then copies that "master" manifest to the various projects including wars and ejbs. Here is my manifest
Manifest-Version: 1.0 Class-Path: lib/my-commons.jar lib/urlrewrite-2.5.1.jar lib/standard.jar lib/myfaces-all.jar lib/jstl.jar lib/jsf-facelets.jar lib/jakarta-oro.jar lib/el-ri.jar lib/el-api.jar lib/commons-validator.jar lib/commons-logging.jar lib/commons-lang-2.1.jar lib/commons-httpclient-3.0-rc3.jar lib/commons-fileupload.jar lib/commons-el.jar lib/commons-digester.jar lib/commons-collections.jar lib/commons-codec.jar lib/commons-beanutils.jar
here is my current application.xml file which I am using as a work around until i figure out why the manifest classes aren't being loaded...
<?xml version="1.0" encoding="UTF-8"?> <application xmlns="http://java.sun.com/xml/ns/j2ee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" version="1.4" xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/application_1_4.xsd"> <display-name>myear</display-name> <module > <web> <web-uri>web1.war</web-uri> <context-root>/web1</context-root> </web> </module> <module> <web> <web-uri>web2.war</web-uri> <context-root>/web2</context-root> </web> </module> <module> <ejb>ejb.ejb3</ejb> </module> <module> <ejb>aop.aop</ejb> </module> <module> <java>lib/myfaces-all.jar</java> </module> <module> <java>lib/my-commons.jar</java> </module> <module> <java>lib/jsf-facelets.jar</java> </module> <module> <java>lib/el-ri.jar</java> </module> <module> <java>lib/el-api.jar</java> </module> </application>
I really think this has something to do with myfaces because the errors are only on the myfaces related jars that need to be loaded via the application.xml in order for my app to work. My my-commons.jar also needs to be loaded because it contains custom jsf components so it too is jsf related. Could this have something to do with the myfaces org.apache.myfaces.webapp.StartupServletContextListener?
A potential conflict with myfaces is that we bundle it with our tomcat, and if its not using the correct thread context class load I could see a problem. You could try removing the jbossweb-tomcat55.sar/jsf-libs to see if that is somehow conflicting. Alternatively, you could just remove the myfaces classes from your deployment.
Already removed the jbossweb-tomcat55.sar/jsf-libs because that was definitely casuing a problem since i was using a more up to date version of them than what came with JBoss. I suppose i could remove the libraries from my deployment or replace the libraries in jbossweb-tomcat55.sar/jsf-libs with the more up to date libraries but something about that feels wrong...what happens when i get this ear deployed to production and then i want to deploy another ear with new jsf libs? Do i risk the deployed ear breaking. Maybe not a huge problem but still a concern. Anyway, the current solution of just including the libraries in the application.xml file seems to work alright. I appreciate you looking into this Scott. Let me know if you think of anything else. Thanks
Hi We have problem with JBOSS 4.0.3 as it is not looking into the manifest file. We have the following directory structure from JBOSS default directory.
in our EAR deployed in deploy directory we have the following mainfest file under META-INF director in the EAR package.
class-path: ../applib/appUtilities.jar ../commonlib/ DOM4j.jar
Now in JBOSS 4.0.3 version it is not loading the appUitlities.jar and DOM4j.jar. But it is working fine in 4.0.2
Any help is appreciated
We have the same problem in Jboss 4.0.2 except we can get it to work. I am deploying a ear file:
Ant-Version: Apache Ant 1.6.5
Created-By: 1.5.0_05-b05 (Sun Microsystems Inc.)
Class-Path: jar1.jar jar2.jaIt finds the jars eventually but all the configuration files (.xml, properties ) are not found by my servlet. Servlet is deployed part of the war.
If I deploy my application as war only and include all the jars in the WEB-INF/lib then application runs fine. Problem occurs when I try to deploy this as EAR and move the jars out of war to ear.
Any help will be appriciated.