Hi,
On Wed, Jul 20, 2016 at 4:46 AM, Greg Wilkins <gregw_at_webtide.com> wrote:
> I too don't really understand the Implicit mapping? Is that for a named
> dispatch? If so, shouldn't it be called Named?
>
The idea for the implicit boolean in the original proposal was just for
parity with Servlet spec 12.2.1. "implicit" as a mapping was never the
intention. But a while back we discussed there wasn't a practical use case
for even the boolean, so this was dropped altogether.
> I'm also struggling to see how the getMatchValue is ever any different to
> the servlet path?
>
If you have a Servlet mapped to /path/* and you request /path/foo/bar the
result would be:
Mapping match:PATH
Match value:/foo/bar
Pattern:/path/*
Servletpath:/path
So the match value is the part that (in this case) comes in place of the *.
Likewise if you map a Servlet to *.ext and you request /foo/bar.ext the
result would be:
Mapping match:EXTENSION
Match value:/foo/bar
Pattern:*.ext
Servletpath:/foo/bar.ext
As you see they're different from the servlet path in both cases.
>
> 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
>
Something to consider for sure.
The original idea was that the HtppServletRequest class has quite some
methods already, so I thought ordering them a little so to speak would make
it clearer that these 3 belong together. In addition the Mapping type could
be passed to code needing to know something about the mapping used, without
having to pass in the entire request. This somewhat lowers the complexity
at what the dependent code can possibly do.
Hope this helps,
Kind regards,
Arjan Tijms
>
> regards
>
>
>
>
>
>
>
>
>
>
> On 20 July 2016 at 12:24, Greg Wilkins <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> 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> 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> 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>
>>>>> 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>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> On 7 April 2016 at 09:20, Stuart Douglas <
>>>>>> 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@webtide.com> CTO http://webtide.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>>>>
>>>
>>>
>>
>>
>> --
>> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>>
>
>
>
> --
> Greg Wilkins <gregw@webtide.com> CTO http://webtide.com
>