Re: Passing parameters to included JSP files

Thursday, October 18, 2012, 10:18:33 AM, Ionut Prunache wrote:

> Yes, that's what i'm doing now, i invalidate the map when the
> request is set and then rebuild it when a method needs it. It's kind
> of messy because i have to take care not to include the params
> multiple time because each include in an include chain would reset the request.

I'm not sure I understand it well. I assume what we are talking about
is that when a jsp:include is called with jsp:param-s, the value(s) of
the params must be prepended before the values(s) of the already
existing params with the same name. For example, if you have p1=v1,
and then jsp:include has jsp:param p1=v2, then you should end up with
p1=[v2, v1] in the included file. But if I understand it well, you
said that they keep reusing the same single original
ServletRequestWrapper thorough all the nested jsp:include-s, and only
replace the wrapped ServletRequest for each. (And then, when the
inclusion has finised, they restore the previous wrapped
ServletRequest?) So how do they maintain the proper value order,
especially through multiple jsp:includes? Do the param values coming
from that single shared ServletRequestWrapper always appear at the end
of the parameter value lists (the opposite of what FM does...), and
all the params coming from jsp:include-s are coming from the wrapped
ApplicationHttpRequest-s, which have, somehow, has the params coming
from jsp:includes in the proper order? (How are the new
ApplicationHttpRequest initialized anyway? Do they get the inherited
values from the replaced wrapped HttpRequest?)

> On Thu, Oct 18, 2012 at 10:56 AM, Daniel Dekany <[email protected]> wrote:
> Wednesday, October 17, 2012, 10:19:23 PM, Ionut Prunache wrote:
>
>> Yes, that's correct, I'm only seeing "param1" in both page2.jsp and
>> page3.jsp. I should have mentioned that i'm using tomcat as application server.
>>
>> I found out why it's not working, at least for me, after some
>> debugging. The problem comes from the combination of Freemarker's
>> CustomParamsRequest and apache's implementation of request wrapping
>> and forwarding. CustomParamsRequest is used to wrap the page's
>> HttpServletRequest and pass parameters when performing an ftl
>> include_page. It holds the parameters in a map separated from the
>> wrapped request that it only modifies at construction time. From
>> then on it never updates that map, not even if the wrapped request gets changed.
>> And that's where it conflicts with apache's implementation.
>> Apache's implementation does not wrap around Freemarker's
>> CustomParamsRequest wrapper when performing an include,  instead it
>> just creates a new ApplicationHttpRequest, it's request wrapper, and
>> replaces the request wrapped by CustomParamsRequest.
>
> They don't create a new ServletRequestWrapper to wrap the original
> request... the modify the current request. Ouch. But, the Servlet (and
> JSP) sepc. is rather vague, so it's not like formally they violate
> anything.
>
>> Because CustomParamsRequest never checks that it's request changes
>> and always serves it's initial parameters, any new parameters added
>> by the changes are never visible.
>>
>> I managed to make it work by hacking  CustomParamsRequest and
>> rebuilding freemarker.jar. I'm using this for now and i hope it's
>> good enough until i manage to complete the transition from JSP to ftl.
>
> So what it should do is, checking if the wrapped request was replaced,
> and if it was, re-build the internal parameter map. Right?
>
>> On Wed, Oct 17, 2012 at 7:12 PM, Daniel Dekany <[email protected]> wrote:
>> Wednesday, October 17, 2012, 3:06:30 PM, Ionut Prunache wrote:
>>
>>> I'm working on a project for replacing an existing JSP code base
>>> with Freemarker. I'm trying to do it progressively, that is I still
>>> want to be able to include some JSP files from my new Freemarker templates.
>>>
>>> The JSP pages that I include directly from .ftl files work fine,
>>> but there is a problem when a JSP page included from an ftl tries to
>>> include another JSP page and pass it some parameters. The second JSP
>>> file loads but doesn't receive the parameters from the calling JSP,
>>> it only gets the parameters that the .ftl passed to the first JSP.
>>>
>>> Here is a short example of the flow:
>>>
>>> page1.ftl
>>> ...
>>> <@include_page path="/WEB-INF/jsp/page2.jsp" inherit_params=true params={"param1": "param1"}/>
>>> ...
>>>
>>> page2.jsp
>>> ...
>>> <jsp:include page="/WEB-INF/page3.jsp">
>>>     <jsp:param name="param2" value="${someVar}"/>
>>> </jsp:include>
>>> ...
>>>
>>> request.getParameterNames() only contains param1 for both page2.jsp
>>> and page3.jsp. I expect page3.jsp to see both param1 and param2.
>>
>> Just to be sure, you are seeing "param1" only, in both page2.jsp and
>> page3.jsp, right? (When you try that, just print them, because
>> getParameterNames might have its own problems.) Then in page2.jsp, the
>> jsp:include didn't add "param2" to the request. That's the jsp:include
>> implementation's doing, and I don't see why it's happening. What's the
>> class of the request object in page2.jsp and in page3.jsp?
>>
>>> Is there a way for this to work? If so, what am i doing wrong?
>>>
>>> Thanks
>>> Ionut
>>
>> --
>> Best regards,
>>  Daniel Dekany
>>
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> FreeMarker-user mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/freemarker-user
>
> --
> Best regards,
>  Daniel Dekany
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> FreeMarker-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freemarker-user

-- 
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct