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


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)" <jira@apache.org>

11.03.2008 09:11
Please respond to

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