I have a custom context classloader that worked with any Tomcat 4 and 5 versions, excepted 5.5.12. With Tomcat 5.5.12, my loader can't find classes from Tomcat jar files (jar files from /common/lib). The problem is that custom loader's constructor receive an instance of AppClassloader (it looks like it is the 'System' classloader). Previously loader's constructor received an instance of StandardClassloader (which should be the 'Common' classloader) I found the following change in Tomcat 5.5.12 compared to Tomcat 5.5.9 : in Tomcat 5.5.9 'addRuleInstances' method in 'ContextRuleSet' class contained the following line : digester.addRule(prefix + "Context", new CopyParentClassLoaderRule()); In Tomcat 5.5.12, this line was removed. Reintegrting this line solve my problem. Maybe this removal was done on purpose but I didn't find any explanation for it. Bruno
This rule is useless.
(In reply to comment #1) > This rule is useless. I don't like to reopen a bug, but for me this is a regression issue that needs some explanations. Maybe this rule is useless, but as I wrote in my previous description, reintroducing this rule fix the problem. I did the a test to see if the problem is the same with the default Loader. I added these lines in server.xml : <Context path="/servlets-examples" docBase="C:\TEMP\servlets-examples" > <Loader className="org.apache.catalina.loader.WebappLoader" /> </Context> This fails in Tomcat 5.5.12 and works in Tomcat 5.5.9. Thank you to do this test, it takes only a few minutes. Bruno
I did some more testings, the problem happens when the context definition is in server.xml, if the context definition is in its own individual file it works. So there are two solutions to fix this regression : - fix the bug by reintroducing the rule or finding another technical solution. - update the documentation by changing this sentence "Please note that for tomcat 5, unlike tomcat 4.x, it is NOT recommended to place <Context> elements directly in the server.xml file" by "Please note that for tomcat 5.5, unlike tomcat 4.x, it is NOT SUPPORTED to place <Context> elements directly in the server.xml file" As written in the changelog this removal was based on the feelings that this rule was useless and that "maybe it used to be useful", so yes it was very useful before Tomcat 5, when defining context in server.xml was the recommended way. >------------------------------------------------------------------------ >r303856 | remm | 2005-04-15 01:58:46 -0700 (Fri, 15 Apr 2005) | 4 lines >- I don't see the purpose of the copy CL rule, as >ContainerBase.getParentClassLoader will return the parent class loader anyway. >If a custom parent is set, the rule will dumbly override it, thus it seems it >never serves a useful purpose. Maybe it used to be useful. Bruno
We too had this problem and I spent a few days trying to figure it out. We have one project using 5.5.9 and it worked fine. So we used their same environment but with Tomcat 5.5.16 and was having problems. I ended up downloading all the tomcat versions from 5.5.9 to 5.5.17 to find out what was causing the problem. When going form 5.5.x to 5.5.y, one would expect minor changes and bug fixes only. Perhaps it's just a confusion about the versioning system, but I believe such a minor increment should not have regression issues. I vote to add the rule back, and to make the change for the next major version, 5.6 or 6.0 or whatever. I could understand if the rule was removed because it was causing problems, but to remove it simply because it was thought to be useless is a bit careless, especially now with evidence to the contrary. -Michael
I also agree that this change should either be reverted (my preference) or the documentation for the Loader element changed. We had a working Tomcat application (using a custom classloader) that unexpectedly broke when migrating from 5.0 to 5.5.16. It took me several frustrating hours to track it down. For anyone else following this issue, there are at least two other related bugs: ASF Bugzilla Bug 37054, ASF Bugzilla Bug 37302.
Sorry, one of the related bugs in my last comment pointed back to this one. The related bugs are: ASF Bugzilla Bug 37054, ASF Bugzilla Bug 38877.
*** This bug has been marked as a duplicate of 37054 ***