On 29/11/17 13:25, Rémy Maucherat wrote: > On Wed, Nov 29, 2017 at 1:12 PM, Mark Thomas <ma...@apache.org> wrote:
<snip/> > Yes, I'm aware of the deployer problems, and the rest makes sense too. I > have no credible way to make it really work right now, unfortunately, > having to disable the auto deployer makes it unusable (IMO). >From memory the original use case related to EAR deployments so I'm not sure if a Tomcat user would ever need it. There is always the wait and see option. If there is user demand for it then we can try and figure out how to make it work at that point. We'd have some users to help us figure out what is and isn't a reasonable restriction on the usage of the feature. >> Regarding the mapping path changes... >> >>> Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationDispat >> cher.java >>> URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/ca >> talina/core/ApplicationDispatcher.java?rev=1816617&r1= >> 1816616&r2=1816617&view=diff >>> ============================================================ >> ================== >>> --- tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java >> (original) >>> +++ tomcat/trunk/java/org/apache/catalina/core/ApplicationDispatcher.java >> Wed Nov 29 09:46:00 2017 >>> @@ -626,7 +626,9 @@ final class ApplicationDispatcher implem >>> wrequest.setQueryString(queryString); >>> wrequest.setQueryParams(queryString); >>> } >>> - wrequest.setMapping(mapping); >>> + if (!Globals.STRICT_SERVLET_COMPLIANCE) { >>> + wrequest.setMapping(mapping); >>> + } >>> >>> invoke(state.outerRequest, state.outerResponse, state); >>> } >> >> -1 (veto) to the above. >> >> See the Javadoc: >> >> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ >> http/HttpServletRequest.html#getHttpServletMapping-- >> >> Also sections 9.3.1 (includes), 9.4.2 (forwards) and 9.7.2 (async >> dispatches) of the Servlet 4.0 spec. >> >> In short, the EG decided to follow the same rules for the mapping as the >> other request properties. >> > > Actually, the javadoc says AsyncContext.dispatch behaves the same as an > include (it is odd though, but that's what it says). So I think this one > should be right. Hmm. Let me do some more research on that. That certainly isn't my recollection of the EG discussions. I wonder if something got lost in translation between the EG and the spec updates or if my memory is failing me. Consider my veto withdrawn. If my memory is correct then +1 to using SERVLET_SPEC_COMPLIANCE to switch between the current, EG intended behaviour and the behaviour described by the spec. >>> Modified: tomcat/trunk/java/org/apache/catalina/core/ApplicationMappin >> g.java >>> URL: http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/ca >> talina/core/ApplicationMapping.java?rev=1816617&r1=1816616& >> r2=1816617&view=diff >>> ============================================================ >> ================== >>> --- tomcat/trunk/java/org/apache/catalina/core/ApplicationMapping.java >> (original) >>> +++ tomcat/trunk/java/org/apache/catalina/core/ApplicationMapping.java >> Wed Nov 29 09:46:00 2017 >>> @@ -19,6 +19,7 @@ package org.apache.catalina.core; >>> import javax.servlet.http.HttpServletMapping; >>> import javax.servlet.http.MappingMatch; >>> >>> +import org.apache.catalina.Globals; >>> import org.apache.catalina.mapper.MappingData; >>> >>> public class ApplicationMapping { >>> @@ -47,7 +48,8 @@ public class ApplicationMapping { >>> mapping = new MappingImpl("", "", >> mappingData.matchType, servletName); >>> break; >>> case DEFAULT: >>> - mapping = new MappingImpl("", "/", >> mappingData.matchType, servletName); >>> + String match = Globals.STRICT_SERVLET_COMPLIANCE >> ? "default" : ""; >>> + mapping = new MappingImpl(match, "/", >> mappingData.matchType, servletName); >>> break; >>> case EXACT: >>> mapping = new MappingImpl(mappingData.wrappe >> rPath.toString().substring(1), >> >> -1 (veto) >> >> See the Javadoc: >> >> https://javaee.github.io/javaee-spec/javadocs/javax/servlet/ >> http/HttpServletMapping.html >> >> In particular the table in the interface description. >> > > Huuuum, yes, I don't understand where the thing came from. >From memory that was one of the options the EG considered but ultimately rejected. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
