Ryan Lubke wrote:
> Adam Winer wrote:
>> Ryan Lubke said the following on 9/21/07 12:03 AM PT:
>>> Adam Winer wrote:
>>>> I'm frankly amazed at the claim this worked in 1.1.
>>>> The EL in 1.1 was bound to ExternalContext.getRequestParameterMap(),
>>>> which is always the ServletRequest parameter map, *not* the
>>>> current JSP parameter map - or was there magic in 1.1 that I didn't
>>>> know about?
>>> Not following you here Adam. What JSP parameteter map?
>>> When a JSP include is performed and it specifies parameters, those
>>> params will be present for the life of the include via the
>>> ServletRequest.
>>
>> Hrm - I always guessed that it was a different ServletRequest
>> instance that gets created for the include to add the needed
>> parameters, instead of the servlet engine hacking into
>> its own object to add and then later remove the parameters.
>> (It's how I'd implement a servlet engine, at any rate.)
>> Does the servlet spec really require it's the same instance
>> across includes?
> Ah, ok. By default, the container *does* wrap the request (I added
> println() calls in each JSP to confirm.
>
> I made the assumption that the request had to be the same in order for
> this to have ever worked in 1.1. So how did it work then? Running the
> same set of modified JSPs in 1.1 show:
>
> 05 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
> inc1 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
> inc2 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
> inc3 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
> inc2 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
> inc3 -> com.sun.faces.context.MyHttpServletRequestWrapper_at_1ae90c
>
> This was present in the ctor of ExternalContextImpl in 1.1:
>
> if (RIConstants.IS_UNIT_TEST_MODE) {
> this.request = request;
> } else {
> // PENDING(craigmcc) - Work around a Tomcat 4.1 and 5.0 bug
> // where the request wrapper used on a
> // RequestDispatcher.forward() call delegates
> // removeAttribute() and setAttribute() to the wrapped
> // request, but not getAttribute(). This causes attributes
> // set via the RequestMap returned in this class to not be
> // visible via calls to getAttribute() on the underlying
> // request.
> if (request instanceof HttpServletRequest) {
> this.request = new MyHttpServletRequestWrapper
> ((HttpServletRequest) request);
> } else {
> this.request = new MyServletRequestWrapper(request);
> }
> }
>
> So technically, this shouldn't have worked as you stated earlier.
>
At this point, I think the best course of action is not to fix this:
- the spec doesn't require this support
- it only worked as a side effect of another fix and as such
wouldn't have worked if that container didn't have an issue
- the fix may introduce some snags that we don't want to have
to deal with down the road.
Thoughts? Comments?
>>
>>> Because of that, and how we build/rendered the tree in 1.1, it works.
>>
>> If and only if:
>> - It's guaranteed to be the same ServletRequest instance
>> - You didn't have a rendersChildren parent in the parent page
>> around the include
>>
>> -- Adam
>>
>>>
>>>>
>>>> -- Adam
>>>>
>>>>
>>>> Ryan Lubke wrote:
>>>>> Change bundle attached to the issue [1].
>>>>> Please note I've added additional comments to the issue for
>>>>> consideration
>>>>> after having had attached the change bundle.
>>>>>
>>>>>
>>>>> [1] https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=629
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>>> For additional commands, e-mail:
>>>>> dev-help_at_javaserverfaces.dev.java.net
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>