Summary: | Same env-entry (web.xml) and ResourceLink (context) names causes NPE | ||
---|---|---|---|
Product: | Tomcat 5 | Reporter: | John Hutchnson <belwig> |
Component: | Catalina | Assignee: | Tomcat Developers Mailing List <dev> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P3 | ||
Version: | 5.5.23 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | All | ||
Attachments: | Demonstrates the issue |
Description
John Hutchnson
2007-05-30 11:29:37 UTC
More info on having duplicate names in the following scenarios web.xml context descriptor winner ------------ -------------------- ------------ no entry <Environment> <Environment> <env-entry> <Environment> <env-entry> <env-entry> no entry <env-entry> no entry <ResourceLink> <ResourceLink> <env-entry> <ResourceLink> blows up Created attachment 20291 [details]
Demonstrates the issue
Zip contains war and an external context descriptor. The configuration as it is
will genreate the issue. Assumes:
- war is exploded to c:/dev/sandbox/tomcat_bug_test/exploded
- The following is in <GlobalNamingResources> in conf/server.xml
<Environment name="testIt"
value="GlobalNamingResources"
type="java.lang.String"/>
The war has only a web.xml and a jsp with a scriptlet to do a lookup on
java:comp/env/testIt.
(In reply to comment #1) > More info on having duplicate names in the following scenarios > > web.xml context descriptor winner > ------------ -------------------- ------------ > no entry <Environment> <Environment> > <env-entry> <Environment> <env-entry> > <env-entry> no entry <env-entry> > no entry <ResourceLink> <ResourceLink> > <env-entry> <ResourceLink> blows up This needs to be updated slightly to take into account the override property of the <Enviroment> tag in the context descriptor. web.xml context descriptor winner ------------ -------------------- ------------ no entry <Environment> <Environment> <env-entry> <Environment> <env-entry> <env-entry> <Environment override="true"> <env-entry> (same as previous) <env-entry> <Environment override="false"> <Environment> <env-entry> no entry <env-entry> no entry <ResourceLink> <ResourceLink> <env-entry> <ResourceLink> blows up This is related to a change made to fix the following bug: http://issues.apache.org/bugzilla/show_bug.cgi?id=29727 First, it appears that contrary to the documentation (located at http://tomcat.apache.org/tomcat-5.5-doc/config/globalresources.html#Enviroment%20Entries), setting the 'override' attribute of a <Enviroment> tag inside <GlobalNameingResources> to 'true' will never be (and perhaps never was) obeyed. Allowing <env-entry> overrides of global <Enviroment> entries (through <ResourceLinks> in the context descriptor) may, it could be argued, be illegal (not the mention confusing). The current behavior, with the NPE, makes it illegal (intentional or not). However, it could also be argued that, with an external context descriptor, you should be able to override anything set via <env-entry> in web.xml if you wanted to (and this is what the documentation seems to indicate). Finally, there's restoring the previous behavior, which never allows any overriding and always (silently) takes the global value, regardless of any corresponding <env-entry>s or any reloading. Essentially, you can a) make it work as described by the documentation, b) blow up, or c) silently take the global values on load (or reload) always. If b, I recommend blowing up with something more descriptive than the NPE we have now and changing the doco. If c, you could just check if (in org.apache.catalina.deploy.NamingResources.java, line 188), findEnviroment() retuns null. If it does, log a warning and return. If not, do the getOverride() if. You should also update the doco in this case too. if (entries.containsKey(environment.getName())) { ContextEnvironment ce = findEnvironment(environment.getName()); if (ce == null) { // Log a warning: return; } if (findEnvironment(environment.getName()).getOverride()) { removeEnvironment(environment.getName()); } else { return; } } Thanks for the report. This has been fixed so functionality agrees with the current documentation (a). The fix is in svn and will be included in 5.5.25 and 6.0.14. |