Bug 39704 - context with privileged="true" do not setup properly inner loaders
Summary: context with privileged="true" do not setup properly inner loaders
Status: RESOLVED INVALID
Alias: None
Product: Tomcat 5
Classification: Unclassified
Component: Catalina (show other bugs)
Version: 5.5.17
Hardware: PC Windows XP
: P2 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 36852 37054 40272 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-06-02 09:48 UTC by Costin Leau
Modified: 2006-09-08 03:52 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Costin Leau 2006-06-02 09:48:13 UTC
Tomcat 5.5.17. When specifying in TOMCAT/conf/context.xml a loader tag, context
with privileged="true" are not properly setup.

For example with this TOMCAT/conf/context.xml:
[quote]
<!-- The contents of this file will be loaded for each web application -->
<Context>
    <!-- Default set of monitored resources -->
    <WatchedResource>WEB-INF/web.xml</WatchedResource>
    <!-- * ADD THIS *  -->
	 <Loader />
    <!-- Uncomment this to disable session persistence across Tomcat restarts-->
    <!--
    <Manager pathname="" />
    -->

</Context>
[/quote]

gives the following error at startup:
ERROR Exception starting filter BalancerFilter -
org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3604)
java.lang.NoClassDefFoundError: org/apache/tomcat/util/digester/Digester
	at org.apache.webapp.balancer.RulesParser.createDigester(RulesParser.java:65)
	at org.apache.webapp.balancer.RulesParser.<init>(RulesParser.java:43)
	at org.apache.webapp.balancer.BalancerFilter.init(BalancerFilter.java:79)
	at
org.apache.catalina.core.ApplicationFilterConfig.getFilter(ApplicationFilterConfig.java:223)
	at
org.apache.catalina.core.ApplicationFilterConfig.setFilterDef(ApplicationFilterConfig.java:304)
	at
org.apache.catalina.core.ApplicationFilterConfig.<init>(ApplicationFilterConfig.java:77)
	at org.apache.catalina.core.StandardContext.filterStart(StandardContext.java:3600)
	at org.apache.catalina.core.StandardContext.start(StandardContext.java:4193)
	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.deployDirectory(HostConfig.java:904)
	at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:867)
	at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:474)
	at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1122)
	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:1021)
	at org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
	at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1013)
	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:709)
	at org.apache.catalina.startup.Catalina.start(Catalina.java:551)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
	at java.lang.reflect.Method.invoke(Unknown Source)
	at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:294)
	at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:432)
ERROR Error filterStart -
org.apache.catalina.core.StandardContext.start(StandardContext.java:4194)
ERROR Context [/balancer] startup failed due to previous errors -
org.apache.catalina.core.StandardContext.start(StandardContext.java:4215)

Note that this is a default install w/o any custom webapps just with the empty
loader tag added.

It seems that the digester rules do not handle this case appropriately.
Comment 1 Costin Leau 2006-06-02 09:48:29 UTC
It might be related to : http://issues.apache.org/bugzilla/show_bug.cgi?id=38223
Comment 2 Yoav Shapira 2006-06-15 19:00:22 UTC
Just out of curiosity, why would you specify an empty Loader tag?  Do you have a
real use-case with an actual custom loader that causes this?
Comment 3 Costin Leau 2006-06-16 07:09:33 UTC
I am using a custom classloader; the empty tag is just for demonstration
purposes: i.e. no matter if you specify a classloader or not, just having the
tag produces an error.
Comment 4 Costin Leau 2006-08-17 07:44:55 UTC
Is there a reason why this bug is still marked as NEEDINFO? What other
information is required?
Comment 5 Mark Thomas 2006-08-22 01:44:18 UTC
*** Bug 40272 has been marked as a duplicate of this bug. ***
Comment 6 Mark Thomas 2006-08-22 02:02:38 UTC
*** Bug 36852 has been marked as a duplicate of this bug. ***
Comment 7 Mark Thomas 2006-08-22 02:04:46 UTC
Problem is due to the way custom loaders are handled on start-up. I can
re-produce it and am working on a fix.
Comment 8 Mark Thomas 2006-08-30 03:41:00 UTC
*** Bug 37054 has been marked as a duplicate of this bug. ***
Comment 9 Mark Thomas 2006-08-31 02:17:48 UTC
With so many duplicates a brief re-cap seems in order. The bug only occurs if:
- Context is specified in server.xml with privilegded="false" and a Loader tag

I haven't found any other combinations that fail.

Note that this issue is a side-effect of fixing embedding bug
http://jira.jboss.com/jira/browse/JBAS-1688
Comment 10 Nicklas Karlsson 2006-08-31 08:14:56 UTC
(In reply to comment #9)
> With so many duplicates a brief re-cap seems in order. The bug only occurs if:
> - Context is specified in server.xml with privilegded="false" and a Loader tag
> 
> I haven't found any other combinations that fail.
> 
> Note that this issue is a side-effect of fixing embedding bug
> http://jira.jboss.com/jira/browse/JBAS-1688

This issue appears also when deploying an application using Eclipse WTP with a
context.xml containing a custom loader that ends up in conf\Catalina\localhost,
resulting in failure to load system libraries.
Comment 11 Costin Leau 2006-08-31 08:29:43 UTC
(In reply to comment #9)
> With so many duplicates a brief re-cap seems in order. The bug only occurs if:
> - Context is specified in server.xml with privilegded="false" and a Loader tag
> 
> I haven't found any other combinations that fail.
> 
> Note that this issue is a side-effect of fixing embedding bug
> http://jira.jboss.com/jira/browse/JBAS-1688

Bug http://issues.apache.org/bugzilla/show_bug.cgi?id=40272 is not a duplicate -
as Nicklas pointed out when specifying a classloader (be it custom or the one
used by default by Tomcat) which Eclipse WTP does, the classloader is not
properly set.
I suspect the digester rules are not properly set for this case (as it was the
case of this bug).
Comment 12 Mark Thomas 2006-08-31 10:50:12 UTC
I have a fix that works for Loaders defined in server.xml. I'll test the Eclipse
WTP case as well.
Comment 13 Mark Thomas 2006-09-01 03:10:28 UTC
The latest release of WTP (1.5.0) doesn't appear, at least for me, to create a
custom loader. However, it does define the context in server.xml and if a custom
loader were configured this bug would occur. My proposed fix will address this
situation so all versions of WTP should be fine once the fix is in place.
Comment 14 Mark Thomas 2006-09-01 11:28:29 UTC
Fixed in SVN and will be in 5.5.19 onwards.
Comment 15 Remy Maucherat 2006-09-01 13:39:15 UTC
The report is actually invalid: conf/context.xml will be processed first, then
the context.xml inside the context will be processed. As a result, the Loader
will be always created with privileged set to "false", since this is its value
in conf/context.xml. The workaround is to have your custom Loader disregard the
parent CL which is passed to it, and then retrieve the right one later on.

The only solution is to merge the XML files before parsing (instead of doing the
successive processing), but it's a bit difficult to do ...
Comment 16 Nicklas Karlsson 2006-09-05 06:09:39 UTC
Marks version was working for me (the WTP case) but the latest svn-version fails
startup silently with

5.9.2006 9:10:45 org.apache.coyote.http11.Http11BaseProtocol init
INFO: Initializing Coyote HTTP/1.1 on http-8080
5.9.2006 9:10:45 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 1275 ms
5.9.2006 9:10:45 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
5.9.2006 9:10:45 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/5.5
5.9.2006 9:10:45 org.apache.catalina.core.StandardHost start
INFO: XML validation disabled
log4j:WARN No appenders could be found for logger
(org.apache.catalina.startup.TldConfig).
log4j:WARN Please initialize the log4j system properly.
5.9.2006 9:10:45 org.apache.catalina.core.StandardContext start
SEVERE: Error listenerStart
5.9.2006 9:10:45 org.apache.catalina.core.StandardContext start
SEVERE: Context [/Concept] startup failed due to previous errors
Comment 17 Mark Thomas 2006-09-07 01:56:41 UTC
A better fix has just been commited. See
http://marc.theaimsgroup.com/?l=tomcat-dev&m=115759391916655&w=2
Comment 18 Nicklas Karlsson 2006-09-07 08:45:16 UTC
(In reply to comment #17)
> A better fix has just been commited. See
> http://marc.theaimsgroup.com/?l=tomcat-dev&m=115759391916655&w=2

The WTP case still fails to load the context with the custom classloader for me.
Comment 19 Mark Thomas 2006-09-07 11:29:34 UTC
Did set useSystemClassLoaderAsParent="false" on the custom loader? Without this
you will see the old behaviour.
Comment 20 Nicklas Karlsson 2006-09-08 05:56:08 UTC
(In reply to comment #19)
> Did set useSystemClassLoaderAsParent="false" on the custom loader? Without this
> you will see the old behaviour.

That did the difference. It seems to be working now. 
Comment 21 Mark Thomas 2006-09-08 10:52:58 UTC
Great. Thanks for the confirmation.