ENV: JDK 1.5.0_05 Tomcat 5.5.12 JAMonapi ( jamonapi.sf.net ) 020106 Linux or Windows I am using JAMonapi war file as a simple example test case, however I expect the problem to occur with any webapp deployed in the same way. According to Tomcat 5.5. documentation: http://tomcat.apache.org/tomcat-5.5-doc/appdev/deployment.html - Shared Library Files http://tomcat.apache.org/tomcat-5.5-doc/class-loader-howto.html "Shared - This class loader is the place to put classes and resources that you wish to share across ALL web applications (unless Tomcat internal classes also need access, in which case you should put them in the Common class loader instead). All unpacked classes and resources in $CATALINA_BASE/shared/classes, as well as classes and resources in JAR files under $CATALINA_BASE/shared/lib, are made visible through this class loader. If multiple Tomcat instances are run from the same binary using the $CATALINA_BASE environment variable, then this classloader repositories are relative to $CATALINA_BASE rather than $CATALINA_HOME." Basic Test Setup - the steps below are for reference. See the attached zip files for the complete test CATALINA_BASE files for four test cases. TWO PASS, TWO FAIL. 1. Install tomcat 5.5.12 and add env. variable CATALINA_HOME to point to the directory of the installation. 2. Create a CATALINA_BASE directory with all the prerequisite directories: conf/ logs/ shared/lib temp/ webapps/ work/ 3. Add an CATALINA_BASE env variable to point to the base directory made in step 2 4. Add a shared library to the $CATALINA_BASE/shared/lib dir. In this case it will be JAMon-020106.jar. 5. Install simple config files to $CATALINA_BASE/conf - server.xml, web.xml, tomcat-users.xml ( see zip files ) 6. Create a standard context file called JAMon.xml and install to $CATALINA_BASE/conf/<enginename>/<hostname>/JAMon.xml ($CATALINA_BASE/conf/test-engine/localhost/JAMon.xml in the tests) 7. Edit the following files as required with the correct paths in the failing test cases: Correct the docBase in $CATALINA_BASE/conf/test-engine/localhost/JAMon.xml to point to either the JAMon.war file or the expanded webapp in a directory. According to the tomcat documentation I expect the test cases which fail to pass. To run the tests I used 'catalina.sh start' and 'catalina.bat start'. Examine the contents of catalina.out in CATALINA_BASE/logs dir for the ClassNotFoundException after starting the container. IN the failing tests if the shared jar file contents are placed in $CATALINA_BASE/shared/classes it also results in ClassNotFoundException. It should look like this: $ cat ./logs/catalina.out 15-May-2006 8:57:53 PM org.apache.coyote.http11.Http11BaseProtocol init INFO: Initializing Coyote HTTP/1.1 on http-7082 15-May-2006 8:57:53 PM org.apache.catalina.startup.Catalina load INFO: Initialization processed in 1094 ms 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardService start INFO: Starting service test 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardEngine start INFO: Starting Servlet Engine: Apache Tomcat/5.5.12 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardHost start INFO: XML validation disabled 15-May-2006 8:57:54 PM org.apache.catalina.startup.ContextConfig applicationWebConfig INFO: Missing application web.xml, using defaults only StandardEngine[test-engine].StandardHost[localhost].StandardContext[] 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardContext filterStart SEVERE: Exception starting filter JAMonFilter java.lang.ClassNotFoundException: com.jamonapi.JAMonFilter at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1338) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1187) at org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:211) at org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:308) at org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:79) at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3563) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4133) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:759) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524) at org.apache.catalina.startup.HostConfig.deployDescriptor(HostConfig.java:603) at org.apache.catalina.startup.HostConfig.deployDescriptors(HostConfig.java:535) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:470) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020) at org.apache.catalina.core.StandardHost.start(StandardHost.java:718) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442) at org.apache.catalina.core.StandardService.start(StandardService.java:450) at org.apache.catalina.core.StandardServer.start(StandardServer.java:680) at org.apache.catalina.startup.Catalina.start(Catalina.java:536) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413) 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardContext start SEVERE: Error filterStart 15-May-2006 8:57:54 PM org.apache.catalina.core.StandardContext start SEVERE: Context [/JAMon] startup failed due to previous errors 15-May-2006 8:57:55 PM org.apache.coyote.http11.Http11BaseProtocol start INFO: Starting Coyote HTTP/1.1 on http-7082 15-May-2006 8:57:55 PM org.apache.catalina.storeconfig.StoreLoader load INFO: Find registry server-registry.xml at classpath resource 15-May-2006 8:57:55 PM org.apache.catalina.startup.Catalina start INFO: Server startup in 1249 ms
Created attachment 18292 [details] testcases 2 passing see the README.txt in each test case dir for info
Created attachment 18293 [details] testcases 2 failing see the README.txt in each test dir
clarify summary
Wondering why this issue is not being looked at?
Peter, issues can be ignored for many reasons. We appreciate your bug reports, and as you can see no one has questioned its contents. However, no one appears to care enough to comment, vote, or provide a patch. Please remember that most of us are volunteers, we don't get paid to fix a specific bug. That's why the best chance for a speedy fix of this issue is if you provide a working patch as an attachment to this Bugzilla item. I'm also downgrading the severity of this issue, because there's an easy workaround of putting the relevant class(es) or jar(s) in the webapp-specific classloader repositories.
Shapira, To add to what Peter Lynch had experienced, what if theres exists a need for a set of classes to be shared across all the contexts. In this case, the ideal place is shared/lib, though the shared classes can be placed in tomcat/common too. When we place the required jar in common/lib, the classes reffered within the shared classes that are not actually shared across contexts also need to be placed there. Am I correct ?
Jain, /shared/lib and /shared/classes do work in Tomcat 5.5.23. The problem that Peter was experiencing is due to a specific advanced configuration, where the webapp is being deployed by using a context.xml file. When the app is deployed into webapps folder, as is the usual way, everything is fine. I have not tested and do not know if and why Peter's deployment using context xml file behaves differently. As far as I understand, the existence of /shared/lib is a requirement of Servlet Spec. E.g. in Servlet Spec. 2.4 chapter SRV.9.7.1 we may read "When a number of applications make use of the same code or resources, they will typically be installed as library files in the container. (...) The container must provide a directory for these libraries. The files placed within this directory must be available across all Web applications. The location of this directory is container-specific." Konstantin.
Found the cause: The context files of those applications that are failing have privileged="true" on their <Context> element. If privileged flag is set, the Webapp classloader of the application uses the Server (aka Catalina) classloader instead of the Shared one as its parent. That is by design and WONTFIX. Though that is not mentioned in class-loader-howto.html, it is mentioned in the description of the privileged attribute of Context here: http://tomcat.apache.org/tomcat-5.5-doc/config/context.html *** This bug has been marked as a duplicate of bug 44094 ***