EB> Mark, do you think the correct behavior in the CONTEXT_ROOT case of [1] EB> is to return ServletC? MT> If it is ServletC that is providing the response, then yes. To that end, here is the

Hello Volunteers, Here is a schedule update: 2017-07-10 21 Day PFD End 2017-07-18 Hand FAB materials to JCP 2017-07-25 14 Day FAB Start 2017-08-07 14 Day FAB End 2017-08-10 GA Release To that

<snip/> If it is ServletC that is providing the response, then yes. Mark

Surely the context path of a webapp should not affect the return from getServletName at all. Also, I thought that most containers have a default servlet deployed with a name "default". Jetty

On 28/06/17 17:14, Edward Burns wrote: Spec> String getMatchValue() Return the portion of the URI path that Spec> caused this request to be matched or the empty String if not known Spec> or not

I can understand when a DEFAULT match may return "" for getServletName() - when the container provides this functionality without using an explicitly configured Servlet. But when can a CONTEXT_ROOT

+1 for me. -- Greg Wilkins <gregw@...> CTO http://webtide.com

+1 from me. I'm not really sure at all when a container would not known why it selected a Servlet. Especially since the parts of the request based on which this choice is made don't have such a

Hello Volunteers, Consider these methods in HttpServletMapping Spec> String getMatchValue() Return the portion of the URI path that Spec> caused this request to be matched or the empty String if

Yes. Yes. Note that these changes are consistent with what was discussed on the EG and users list as the expected behaviour. +1. I know I missed your deadline but I hope this change is

Ed, your examples and text look good to me. cheers -- Greg Wilkins <gregw@...> CTO http://webtide.com

EB> I would very much like to stick with the existing resolution. That EB> said, yes, it is a draft. I need to see if we can make a change like EB> this without having to do another Proposed Final

GW> what was finally decided about the named dispatchers? I think the null GW> return is wrong, but I'm guessing too late to change??? Although it is GW> still a draft????? I realize that I gave you

+1 Mark

Ed, what was finally decided about the named dispatchers? I think the null return is wrong, but I'm guessing too late to change??? Although it is still a draft????? Can we have a tagged release of

the link is wrong : https://jcp.org/aboutJava/communityprocess/pfd/jsr369/index.html

The Proposed Final Draft has been posted to jcp.org! https://jcp.org/aboutJava/communityprocess/pfd/jsr369/ Congratulations everyone! Ed

Ed, I think that when using a Dispatcher obtained from getNamedDispatcher, then nothing about the request is actually changed. The servletPath and pathInfo remain the same, it is just that a

Hello Volunteers, Here is a heads up that we have handed the Proposed Final Draft of the spec to the JCP this week. The only difference between the Public Review and the Proposed Final Draft is the

SD> Another alternative would be to add a MappingMatch of NAMED, use SD> getServletName() to return the name, and have pattern and matchValue SD> return null (or the empty string). SD> I think this