Hi,
On Thu, Feb 9, 2017 at 10:38 AM, Mark Thomas <markt_at_apache.org> wrote:
> 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.
Indeed, the Tomcat implementation performed very well. Waiting for Undertow
and Jetty, and hopefully soon GF 5 as well then ;)
> 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.
I'm also not sure where this came from. It's not something I proposed at
least, and I don't think it should be really necessary, but perhaps someone
(Ed?) can explain this.
Kind regards,
Arjan Tijms
>
>
> 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
>>
>
>