You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2006/01/27 23:51:40 UTC
DO NOT REPLY [Bug 37424] - welcome-file list not working with extensions
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=37424>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=37424
------- Additional Comments From jan.luehe@sun.com 2006-01-27 23:51 -------
I don't see where exactly the problem of supporting an extension match for
welcome pages lies.
I've searched both the servlet and jsp specs for references to default
(implicit) welcome pages, but could not find any.
Notice that in the list of welcome pages declared in default-web.xml:
<welcome-file-list>
<welcome-file>index.html</welcome-file>
<welcome-file>index.htm</welcome-file>
<welcome-file>index.jsp</welcome-file>
</welcome-file-list>
index.jsp comes last. Also notice this comment in default-web.xml:
<!-- If you define welcome files in your own application's web.xml -->
<!-- deployment descriptor, that list *replaces* the list configured -->
<!-- here, so be sure that you include any of the default values that -->
<!-- you wish to include.
Therefore, the welcome pages declared in default-web.xml, and in particular the
index.jsp welcome page, will never interfere with any application-defined
welcome pages.
This means that if a webapp declares its own welcome file list, the index.jsp
welcome file from the default-web.xml, for which an extension mapping always
exists, will not be considered and will not be able to "hijack" any of the
webapp's welcome pages.
I think Mapper.java could be modified as follows: I've moved the existing Rule
4c to 4d, and inserted a new rule 4c that performs the extension mapping. That
failing, Rule 4d is invoked, which checks if the welcome file exists as a
physical resource, and if so, maps it to the default servlet. That still
failing, the next welcome file in the list is checked:
// Rule 4a -- Welcome resources processing for exact macth
internalMapExactWrapper(exactWrappers, path, mappingData);
// Rule 4b -- Welcome resources processing for prefix match
if (mappingData.wrapper == null) {
internalMapWildcardWrapper
(wildcardWrappers, context.nesting,
path, mappingData);
}
// Rule 4c -- Welcome resources extension match
if (mappingData.wrapper == null) {
internalMapExtensionWrapper(extensionWrappers,
path, mappingData);
}
// Rule 4d -- Welcome resources processing
// for physical folder
if (mappingData.wrapper == null
&& context.resources != null) {
Object file = null;
String pathStr = path.toString();
try {
file = context.resources.lookup(pathStr);
} catch(NamingException nex) {
// Swallow not found, since this is normal
}
if (file != null && !(file instanceof DirContext)
&& context.defaultWrapper != null) {
mappingData.wrapper = context.defaultWrapper.object;
mappingData.requestPath.setChars
(path.getBuffer(), path.getStart(),
path.getLength());
mappingData.wrapperPath.setChars
(path.getBuffer(), path.getStart(),
path.getLength());
mappingData.requestPath.setString(pathStr);
mappingData.wrapperPath.setString(pathStr);
}
}
Please let me know what you think and if you want me to supply any diffs.
I don't think we need any configuration switch for this feature: It should be
supported by default if approved.
Jan
--
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org