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. Regards Carsten -- Carsten Ziegeler - Open Source Group, S&N AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
