Bug 39589 - $CATALINA_BASE/shared/lib and $CATALINA_BASE/shared/classes libraries not found in specific deployments
Summary: $CATALINA_BASE/shared/lib and $CATALINA_BASE/shared/classes libraries not fou...
Status: RESOLVED DUPLICATE of bug 44094
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.12
Hardware: Other other
: P1 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
Depends on:
Reported: 2006-05-16 00:00 UTC by Peter Lynch
Modified: 2009-01-03 14:53 UTC (History)
0 users

testcases 2 passing (625.10 KB, application/x-gzip)
2006-05-16 00:06 UTC, Peter Lynch
testcases 2 failing (875.57 KB, application/x-gzip)
2006-05-16 00:07 UTC, Peter Lynch

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Lynch 2006-05-16 00:00:41 UTC
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
"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:

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/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
INFO: Missing application web.xml, using defaults only
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.core.StandardContext.start(StandardContext.java:4133)
        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.deployApps(HostConfig.java:470)
        at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
        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 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
Comment 1 Peter Lynch 2006-05-16 00:06:31 UTC
Created attachment 18292 [details]
testcases 2 passing

see the README.txt in each test case dir for info
Comment 2 Peter Lynch 2006-05-16 00:07:21 UTC
Created attachment 18293 [details]
testcases 2 failing

see the README.txt in each test dir
Comment 3 Peter Lynch 2006-05-16 00:16:56 UTC
clarify summary
Comment 4 Peter Lynch 2006-11-17 08:10:03 UTC
Wondering why this issue is not being looked at?
Comment 5 Yoav Shapira 2007-03-25 08:05:58 UTC
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.
Comment 6 Mamta Jain 2007-09-26 23:16:13 UTC

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 ?
Comment 7 Konstantin Kolinko 2007-10-10 05:07:22 UTC

/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."

Comment 8 Konstantin Kolinko 2009-01-03 14:53:43 UTC
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:

*** This bug has been marked as a duplicate of bug 44094 ***