Post by Ionut PrunacheAfter a closer look i think they do not just overwrite the wrapped
HttpRequest. They build a request chain of ApplicationHttpRequests
and the head of this chain is set as the wrapped request in
Freemarker's wrapper. So they manage the parameters correctly, as
you expect, but just put them under the CustomParamsRequest and thus render them invisible.
When they add a new request they go down the request chain until
they find a familiar wrapper, which CustomParamsRequest isn't, and
then wrap the request around that wrapper.
does BTW. If jsp:include was doing the same with the
there wouldn't be any problems... Anyway, I hoped there's some trivial
fix, but it seems it's more involved to figure out.
Post by Ionut PrunacheThat's what i could figure with a little debugging. I'm just
starting to use Freemarker and Java Enterprise so i don't have much
experience with these things.
Best Regads,
Ionut Prunache
Post by Ionut PrunacheYes, 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?)
Post by Ionut PrunachePost by Ionut PrunacheYes, 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.
Post by Ionut PrunacheBecause 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?
Post by Ionut PrunachePost by Ionut PrunacheI'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.
page1.ftl
...
...
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?
Post by Ionut PrunacheIs 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
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
FreeMarker-user mailing list
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
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
FreeMarker-user mailing list
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
http://p.sf.net/sfu/appdyn_sfd2d_oct
_______________________________________________
FreeMarker-user mailing list
https://lists.sourceforge.net/lists/listinfo/freemarker-user