Carsten Ziegeler wrote:
Ate Douma wrote:
The ActionForm CategoryBean used by the Catalog.jsp seems to be filled in during
the actionRequest and stored in the session. During the subsequent renderRequest
the same CategoryBean *is* retrieved again. So, if the DefineTag is getting a
null
value (from catalogBean .getCategory() or .getProductList()) I suggest debugging
the CategoryBean.viewCategory() method which is invoked by the ActionBean
during the actionRequest. That should retrieve and fill in the required values
from
the database. Then, if that works, debug the getCategory() and getProductList()
method when invoked from the defineTag.
Many thanks for the info - now, debugging revealed that the category is
never set,
so the setter of the bean is not invoked. Can you please help me again,
and tell me
who triggers the setter?
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.
Ate
Many thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
