Summary: | Custom context loader unable to find Tomcat jar files | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | bleroux <leroux_bruno> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED DUPLICATE | ||
Severity: | regression | ||
Priority: | P2 | ||
Version: | 5.5.12 | ||
Target Milestone: | --- | ||
Hardware: | Other | ||
OS: | other |
Description
bleroux
2005-10-29 14:07:51 UTC
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. |