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.
It might be related to : http://issues.apache.org/bugzilla/show_bug.cgi?id=38223
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?
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.
Is there a reason why this bug is still marked as NEEDINFO? What other information is required?
*** Bug 40272 has been marked as a duplicate of this bug. ***
*** Bug 36852 has been marked as a duplicate of this bug. ***
Problem is due to the way custom loaders are handled on start-up. I can re-produce it and am working on a fix.
*** Bug 37054 has been marked as a duplicate of this bug. ***
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
(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.
(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).
I have a fix that works for Loaders defined in server.xml. I'll test the Eclipse WTP case as well.
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.
Fixed in SVN and will be in 5.5.19 onwards.
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 ...
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
A better fix has just been commited. See http://marc.theaimsgroup.com/?l=tomcat-dev&m=115759391916655&w=2
(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.
Did set useSystemClassLoaderAsParent="false" on the custom loader? Without this you will see the old behaviour.
(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.
Great. Thanks for the confirmation.