cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gabriel Gruber <>
Subject SSF Secrets or valid enhancements?
Date Mon, 05 Jan 2009 20:54:46 GMT
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 

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&param2=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 

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...


By the way if it is interesting for the public I can post my wicket-cocoon 
integration sample for others!



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)" <> 
11.03.2008 09:11
Please respond to


[jira] Closed: (COCOON-1831) Passing parameters to sub calls



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:
>             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.

View raw message