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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
