Feb 21st, 2007, 03:18 PM
Request-scoped beans in a cross-context dispatch target
Iíve hit some challenges when using Spring Portlet MVC in a portlet-application, when attempting to use request-scoped beans and request attributes. A couple of request-scoped beans would be ideal for the situation.
Portlet-containers typically use a cross-context dispatch to invoke portlets defined in the portlet-application, in a separate context. As a result of the cross-context dispatch, there is no opportunity for the RequestContextFilter or RequestContextListener to execute: you can define them in web.xml (portlet-application), but they will not execute due to the internal dispatch.
As a result, I cannot use RequestContextHolder to access the current request attributes, as the ThreadLocal has not been prepared. Iím wondering anyone has encountered this problem before and has a solution.
One option is to insist that the dispatching context (i.e. the portal) deploys Spring and declares the request context listener or filter. Even this is not quite enough as the attributes-passing mechanism uses Spring classes (RequestAttributes subclasses) to wrap the attributes, so you then need to deploy Spring to a shared classloader. These options result in a non-portable portlet-application and deployment concerns.
The only other options I can see is to either use AOP, or introduce the request context setup functionality via a servlet in these circumstances, as that is the only thing that is guaranteed to be hit.
Perhaps I am missing something - any thoughts appreciated.
Feb 23rd, 2007, 01:00 AM
I've managed to solve this. Turns out the project I am working on had not upgraded from Spring 2.0.0, and I was stung by http://opensource.atlassian.com/proj...rowse/SPR-2758 , where attributes were only being exposed to action requests, not render requests.
Reading that bug report also led to me understanding that the thread request context setup is actually performed by DispatcherPortlet, which I didn't understand at the time of my original post. So as long as your beans sit within the portlet's context scope you can obtain the request attributes. Same for servlets. Nice