On 09/02/17 00:15, Greg Wilkins wrote:
>
> We are looking at implementing this in the next few days.
>
> Firstly it is unclear what mapping should be returned for all dispatch
> types:
There was some discussion on this back in April last year on the users
list. The general idea as that it should be consistent with the value
returned by getServletPath().
So specifically:
> * REQUEST is ok
> * FORWARDED, we guess it is the forwarded mapping, just like
> getServletPath has changed
Returns the forward mapping. Original mapping available via
RequestDispatcher.FORWARD_MAPPING / javax.servlet.forward.mapping
> * INCLUDED, we guess the original mapping is returned, but should the
> included mapping be available as a request attribute like the other
> included path info?
Returns the original mapping. The mapping for the include is available via
RequestDispatcher.INCLUDE_MAPPING / javax.servlet.include.mapping
> * ASYNC, assume it is the dispatched path?
Yes. The original is available via
ASYNC_MAPPING / javax.servlet.async.mapping
> * ERROR, no idea
Returns the error mapping. Original mapping not available
> * what about between dispatches? I assume undefined, but it would be
> good to say as much
> * what about named dispatchers?
Original mapping. No attributes set.
Tomcat has implemented above with the exception of making the original
available via an attribute for ASYNC. Arjan did some testing with that
implementation and was happy with the behaviour. The next steps were for
him to test with other containers once implementations were available.
> Also why does the getMapping() method javadoc say:
>
> Each invocation of this method must return a fresh instance of Mapping.
>
> Why is this needed for an immutable object that contains 3 references to
> other immutable objects?
Don't know. I can't think of a reason for this. Nor do I recall it being
discussed.
> It also says:
>
> The implementation must retain no reference to the returned Mapping.
>
> which is a bit overkill for an immutable object. We don't say that for
> every immutable string or Cookie instance returned by the API?
Again, don't know the reason for this.
HTH,
Mark
>
>
> cheers
>
>
> On 9 February 2017 at 10:39, Mark Thomas <markt_at_apache.org
> <mailto:markt_at_apache.org>> wrote:
>
> On 08/02/17 23:00, Edward Burns wrote:
>
> EB> I addressed the Filter and Listener issue as follows:
>
> EB> HttpServletRequest.getMapping():
>
> EB> If called from a Servlet, return the Mapping by which this
> EB> HttpServletRequest was invoked, otherwise return a Mapping
> equivalent
> EB> to the one specified for the default implementation. Each
> invocation
> EB> of this method must return a fresh instance of Mapping. The
> EB> implementation must retain no reference to the returned
> EB> Mapping. Servlet 4.0 compliant implementations must override
> this
> EB> method.
>
> On Wed, 8 Feb 2017 22:40:02 +0000, Mark
> Thomas <markt_at_apache.org
> <mailto:markt_at_apache.org>> said:
>
>
> MT> Changing the behaviour based on which code is making the
> call will break
> MT> the intended use cases.
>
> MT> Every request is mapped to a servlet. getMapping() should
> return the
> MT> current servlet mapping regardless of where the call
> originates from.
>
> I can certainly do it that way. Do we need to make it more clear by
> changing the name of the method to be getServletMapping()?
>
>
> That makes sense to me. Mapping -> ServletMapping as well? That
> leaves the possibility of FilterMapping in the future should it ever
> be requested.
>
> Mark
>
>
>
>
> --
> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
> http://webtide.com