We are looking at implementing this in the next few days.
Firstly it is unclear what mapping should be returned for all dispatch
types:
- REQUEST is ok
- FORWARDED, we guess it is the forwarded mapping, just like
getServletPath has changed
- 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?
- ASYNC, assume it is the dispatched path?
- ERROR, no idea
- what about between dispatches? I assume undefined, but it would be
good to say as much
- what about named dispatchers?
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?
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?
cheers
On 9 February 2017 at 10:39, Mark Thomas <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> 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@webtide.com> CTO http://webtide.com