On 20/07/2016 04:46, Greg Wilkins wrote:
> Arjan et al,
>
> A few more questions.
>
> I too don't really understand the Implicit mapping? Is that for a
> named dispatch? If so, shouldn't it be called Named?
No. It was for the default and JSP servlet but the consensus was it
served no purpose and could be dropped.
> I'm also struggling to see how the getMatchValue is ever any different
> to the servlet path?
It is the pathInfo for a path match.
It is the servlet path minus the .extension for an extension match. i.e.
the part that matched the * in the 8.extension.
Not sure if it helps but this the result of the conversations I had (on
list) with Arjan:
http://svn.apache.org/viewvc/tomcat/trunk/java/org/apache/catalina/core/ApplicationMapping.java?view=annotate#l34
> I also am seeing little value in aggregating the 3 values into a
> separate class, which is just inviting pointless garbage. Those
> methods could just be put directly on the Request. If they were to be
> aggregated, then contextPath, servletPath, pathInfo, queryString should
> all be included in the aggregate as they are all the many parts that can
> change when a request is dispatched to a servlet. So putting some in an
> aggregate and leaving the others in the request is a bit asymmetric
It ended up being four values but I take your point about the asymmetry.
I have no strong views at this point on aggregation and I'm happy to go
with the consensus view of the EG.
Mark
> On 20 July 2016 at 12:24, Greg Wilkins <gregw_at_webtide.com
> <mailto:gregw_at_webtide.com>> wrote:
>
> arjan,
>
> I'm finally having a go at implementing this. I've hacked up the
> API for now and it looks moderately straight forward for normal
> dispatches, but what I need is a good description of how this should
> be handled with forwards, includes and Async dispatches?
>
> cheers
>
>
> On 13 May 2016 at 16:32, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Thanks for the update Greg, I'll check again in June then.
>
> On Fri, May 13, 2016 at 3:31 AM, Greg Wilkins <gregw_at_webtide.com
> <mailto:gregw_at_webtide.com>> wrote:
>
>
> Sorry, our Servlet 4.0 work has been pushed back a bit. We
> are unlikely to get time to implement until June.
>
>
>
> On 9 May 2016 at 22:37, arjan tijms <arjan.tijms_at_gmail.com
> <mailto:arjan.tijms_at_gmail.com>> wrote:
>
> Hi,
>
> Greg, Stuart, did you already succeeded in implementing
> this in Jetty resp. Undertow? If so, any gotcha's
> encountered?
>
> Kind regards,
> Arjan Tijms
>
> On Mon, Apr 11, 2016 at 12:29 PM, Mark Thomas
> <markt_at_apache.org <mailto:markt_at_apache.org>> wrote:
>
> All,
>
> I've updated Tomcat's implementation as follows:
>
> - added RequestDispatcher.FORWARD_MAPPING
> - added RequestDispatcher.INCLUDE_MAPPING
> - s/getMatchType/getMappingMatch/
> - added Mapping.getServletName()
> - removed MappingMatch.IMPLICIT
>
> The behaviour for forward/include is the same as for
> the other
> forward/include attributes.
>
> This will be included in the next milestone release
> (early May) be if
> folks want to test this sooner than that, let me
> know and I'll publish a
> snapshot.
>
> Mark
>
>
> On 07/04/2016 00:32, Stuart Douglas wrote:
> > Yes, I think returning a mapping of *.jsp when the
> request is to /home
> > would just cause confusion, as in this case the
> jsp implicit mapping
> > does not have anything to do with the request.
> >
> > I am not sure about getDescriptor(), I can't
> really see a use case for
> > it. A filter or servlet should not care where it
> came from, and a
> > human should already know (or be easily able to
> find out by looking at
> > the source).
> >
> > Stuart
> >
> > On Thu, Apr 7, 2016 at 9:27 AM, Greg Wilkins
> <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> wrote:
> >>
> >> On 7 April 2016 at 09:20, Stuart Douglas
> <stuart.w.douglas_at_gmail.com
> <mailto:stuart.w.douglas_at_gmail.com>> wrote:
> >>>
> >>> I was just thinking about this a bit more and it
> might be useful to
> >>> include the target Servlet name in the mapping
> result, so a filter could
> >>> tell exactly what Servlet the request is
> targeted at (we could even take it
> >>> one step further and include a list of the
> filter names that will process
> >>> the request, although I don't know what the use
> case would be).
> >>
> >>
> >>
> >> So for clarity, I'm when we have a mapping like:
> >>
> >> <servlet>
> >> <servlet-name>home</servlet-name>
> >> <jsp-file>/jsp/Home.jsp</jsp-file>
> >> </servlet>
> >> <servlet-mapping>
> >> <servlet-name>home</servlet-name>
> >> <url-pattern>/home</url-pattern>
> >> </servlet-mapping>
> >>
> >> The mapping reported will be the /home mapping
> rather than any *.jsp
> >> implicit pattern.
> >>
> >> You are suggesting that we add getServletName to
> the Mapping, which in this
> >> case would return "home" I see value in that.
> >>
> >> There may even be value in a getDescriptor()
> method that would give a text
> >> description of what descriptor the mapping was
> from: web.xml, fragment
> >> web.xml from a particular jar, annotation on a
> particular class etc.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> Greg Wilkins <gregw_at_webtide.com
> <mailto:gregw@webtide.com>> CTO http://webtide.com
>
>
>
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>>
> CTO http://webtide.com
>
>
>
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com
>
>
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com