Hello Folks, over the holidays I continued my last years playings with Apache Wicket and Cocoon. This time a little bit more successful. I have a working prototype now, where a Wicket Servlet is called by the Servlet Service Framework and the resulting xhtml is postprocessed by some XSLTs inside cocoon. Even Wicket Ajax is working fine!
However in order to get it running I had to make some changes in SSF,
because I discovered these problems:
a) I found no way to foreward the request parameters from the original
HTTP POST Request to the Wicket Servlet, alltough my pipelines looked
correct. But after debugging I discovered that the created
ServletServiceRequest object just didn't contain the request parameters of
the original request.
b) SSF is not capeable of handling redirection of called HTTP servlets
correctly. (HTTP Response 302)
c) some Methods of SSFs 'ServletServiceRespose' class are not implemented,
but needed by the Wicket Servlet, namely: encodeRedirectUrl and
encodeUrl..
In the end it turned out that b) is not a problem, if you change the
RequestCycleStrategy inside Wicket (to use not redirection at all...).
So in order to fix these issues for me I had to make some changes to
cocoon-servlet-service-impl and cocoon-servlet-service-components. While
this patches worked for my usecase I would like to see those changes
integrated into trunk obviously ;-)
I case of the ServletServiceRequest object I was a bit puzzled because in
different posts on the mailing list I read that the "... req params &
attrs and session are passed/shared..." which was the thing I needed.
however it didnot work for me. Looking at the code it seemed to me that
only request parameters which where appended to the called URL (like
myServlet?param1=a¶m2=b)where actually passed, while does which were
POSTED where NOT passed.
As the current behavior is somehow different to my new implementation, I
suggest to implement a marker to switch between old and new behavior...
public String getParameter(String name) {
if (useParentRequest)
return (String) this.parentRequest.getParameter(name);
return (String) this.parameters.getValue(name);
}
How this marker could be implemented? F.i. via another special Postfix in
the servlet-Name (like the one which is used to identify full qualified
servlet-class-names)
If I am wrong with my assumptions, please tell me how I can reach the
desired result without any modifications of this cocoon classes.
Attached are my patches...
WDYT?
By the way if it is interesting for the public I can post my wicket-cocoon
integration sample for others!
cheers,
Gabriel
______________________
Mag. Gabriel Gruber
Senior Consultant
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Workflow EDV GmbH, Dannebergplatz 6/23, A-1030 Wien
----- Forwarded by Gabriel Gruber/Workflow on 05.01.2009 21:31 -----
"Reinhard Poetz (JIRA)" <[email protected]>
11.03.2008 09:11
Please respond to
[email protected]
To
[email protected]
cc
Subject
[jira] Closed: (COCOON-1831) Passing parameters to sub calls
[
https://issues.apache.org/jira/browse/COCOON-1831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Reinhard Poetz closed COCOON-1831.
----------------------------------
Resolution: Fixed
patch applied. req params & attrs and session are passed/shared.
> Passing parameters to sub calls
> -------------------------------
>
> Key: COCOON-1831
> URL: https://issues.apache.org/jira/browse/COCOON-1831
> Project: Cocoon
> Issue Type: New Feature
> Components: - Servlet service framework
> Reporter: Reinhard Poetz
> Assignee: Reinhard Poetz
> Attachments: BlockCallHttpServletRequest.patch,
cocoon-servlet-service-impl.patch, cocoon-servlet-service-impl.patch
>
>
> When a servlet service request is created, parameters from the parent
request are ignored. This means that the sub request is performed as a
fresh and clean new call. This would avoid any possible side-effects, but
is very inconvenient in practice because you don't even know the request
header parameters from the original (external) request. Additionally you
can only pass information which is part of the returned stream, which is
e.g. a blocker to use the servlet protocol together with the control flow
implementations. Those make use of special request parameters to transport
the model ("bizdata") to the view layer.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
cocoon-servlet-service-components.patch
Description: Binary data
cocoon-servlet-service-impl.patch
Description: Binary data
