Carsten Ziegeler wrote:
Ate Douma wrote:
Yes, I think I now see where it is going wrong after looking again at the debug
log
you appended before.
The Struts Bridge uses render parameter _spage to communicate Struts request
parameters
to Struts. If you look in the debug log, you see this as having value:
_spage=/shop/viewCategory.shtml?categoryId=CATS
The StrutsPortlet invokes the StrutsServet using a RequestDispatcher using the
_spage path
from the ServletContext as retrieved from ServletContextProvider (the one you
will have
implemented yourself for Cocoon).
The thing what is going wrong is Servlet 2.3 SRV.8.1.1 spec related.
According to that requirement, query strings in request dispatcher paths must
be made
available to the requested servlet *and* take precedence during the invocation.
In the above example, the query parameter categoryId=CATS therefore should be
visible
to the StrutsServlet.
But, your debug log show only the _spage, _sorig (another StrutsPortlet
parameter) and a
cocoon-portal-event parameter be seen (and tried to be set) by
BeanUtils.populate.
So, I suggest checking your ServletContextProvider implementation and debugging
the
HttpServletRequest(Wrapper) hierarchy as seen by StrutsServlet after it is
invoked from
StrutsPortlet (line: 357).
In Jetspeed, we had this problem too when I started out with the Struts Bridge.
I suspect you
may have a request wrapper in Cocoon which only gives access to the Portlet
request parameters
and forgets to merge the parameters set with the dispatched include call as
provided by Tomcat.
If I remember correctly, I had problems with the Tomcat 4.x handling though and
had to provide
handling for this myself, but with Tomcat >= 5 this was fixed and now the
Struts Bridge expects
this to be done according to the specs by the underlying webserver.
If you would need that old Tomcat 4 handling, please let me know and I can look
it up from
our now old and readonly cvs repo.
Ah, now I found the problem - thanks for your help, Ate - Tomcat
exchanges the request object in the HttpServletRequestWrapper - my own
wrapper was caching the request object itself, therefore always using an
own version without the required parameters :(
Now it works...the Struts based JPetstore runs perfectly inside the
Cocoon portal...Hurrrayy!
I'll just adding Cocoon to the list of supporting projects.
Again, many thanks, Ate! Without you I think I would never have found
the problem.
No problem. Glad to be able to help out.
And having Cocoon on the supported list is great :-)
Ate
Regards
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
