Re: [Springframework-developer] JSF, Spring, and Spring Portlet MVC

[John L. <jl...@un...>]

Jan,

First, please ask questions like this in the Forums
(http://forum.springframework.org/).  You are more likely to get a
response there as a wider range of people are active in the forums than
are watching these quasi-deprecated mailing lists.

Okay, on to the question:

Most portals (all?) implement calls to portlet webapps by obtaining a
javax.servlet.RequestDispatcher for the portlet webapp, and they then
call include(...) on a portal-specific servlet that is added into the
portlet webapp for this purpose.  Normally, Filters and Listeners are
not applied to "include" calls, even when they are across different
servlet contexts.  So, you are likely having problems because the
Filters and Listeners you are configuring are not applied to your
portlet requests at all.

In most cases, the use of DispatcherPortlet is the best way to solve
this problem -- you may want to use this regardless.  One nice thing it
gives you is the ability to wrap HandlerInterceptors around your
requests, which work a lot like Filters.  Another nice thing you can do
here is handle other Portlet Modes (like 'Help') as simple JSP pages
instead of implementing them as JSF.  You can use
PortletWrappingController to turn your JSF Portlet into a Controller for
use with DispatcherPortlet.

Another thing you could try instead:  According the Servlet 2.4 spec,
you can force Filters to be applied to include() calls by adding a
<dispatcher> element to your <filter-mapping> entry.  For example, the
following would apply the filter to normal client requests along with
both include and forward calls from a Dispatcher.

<filter-mapping>
    <filter-name>Request Context Filter</filter-name>
    <servlet-name>PortletServlet</servlet-name>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>INCLUDE</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

The default is that filters are only applied to normal client requests. 
Using this, you may be able to attach the needed filter to the servlet
your portal is using for its cross-context include call and then the
needed attributes may be available to your JSF Portlet.  I haven't tried
this, so I have no idea if it will actually work.  Please report back on
the success or failure of this approach if you attempt it.

Hope all that helps!

John



Jan Nielsen wrote:
> It appears that the Spring bean session scope does not work for JSF
> portlets in LifeRay. When the Spring bean scope is set to "session" in
> the application context, the following error occurs:
>
> 21:02:46,149 ERROR [com.liferay.portal.kernel.servlet.PortletServlet]
> javax.portlet.PortletException: Error creating bean with name
> 'objectService': Scope 'session' is not active for the current thread;
> consider defining a scoped proxy for this bean if you intend to refer
> to it from a singleton; nested exception is
> java.lang.IllegalStateException: No thread-bound request found: Are
> you referring to request attributes outside of an actual web request?
> If you are actually operating within a web request and still receive
> this message,your code is probably running outside of
> DispatcherServlet/DispatcherPortlet: In this case, use
> RequestContextListener or RequestContextFilter to expose the current
> request.
>
> javax.portlet.PortletException: Error creating bean with name
> 'objectService': Scope 'session' is not active for the current thread;
> consider defining a scoped proxy for this bean if you intend to refer
> to it from a singleton; nested exception is
> java.lang.IllegalStateException: No thread-bound request found: Are
> you referring to request attributes outside of an actual web request?
> If you are actually operating within a web request and still receive
> this message,your code is probably running outside of
> DispatcherServlet/DispatcherPortlet: In this case, use
> RequestContextListener or RequestContextFilter to expose the current
> request.
>
>                 at
> com.sun.faces.portlet.FacesPortlet.renderFaces(FacesPortlet.java:364)
>                 at
> com.sun.faces.portlet.FacesPortlet.doView(FacesPortlet.java:280)
>                 at
> javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235)
>                 at javax.portlet.GenericPortlet.render(GenericPortlet.java:163)
>
> We have configured the ContextLoaderListener and the
> RequestcontextListener as follows in our web.xml file
>
>     <listener>
>         <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
>     </listener>
>     <listener>
>         <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
>     </listener>
>
> Tried using the RequestContextFilter with no apparent difference. We
> are using JSF 1.2 RI and the jsf-portlet-bridge.  We are not using
> Spring Portlet MVC or Spring WebFlow.  We are defining all of our
> beans in the Spring context, and using the DelegatingVariableResolver
> to allow JSF to find the Spring beans.  With the new Spring web bean
> scoping in Spring, we were hopeful we could use the scope attribute in
> the bean definition for specifying session scope rather than the
> default request scope.
>
> The solution we are using is to define beans that will be used
> directly in the JSF layer in the faces-config.xml file.  Any
> supporting beans (API services, etc. ) can be defined in the Spring
> context and referenced from the faces-config file.  The
> DelegatingVariableResolver allows the bean definitions in the
> faces-config.xml file to reference beans defined in the Spring
> context. For instance, our bean definition in the faces-config file is
> as follows:
>
>     <application>
>         <variable-resolver>
>             org.springframework.web.jsf.DelegatingVariableResolver
>         </variable-resolver>
>     </application>
>
>     <managed-bean>
>         <managed-bean-name>manager</managed-bean-name>
>         <managed-bean-class>my.package.ObjectManager</managed-bean-class>
>         <managed-bean-scope>session</managed-bean-scope>
>         <managed-property>
>             <property-name>service</property-name>
>             <value>#{objectService}</value>
>         </managed-property>
>     </managed-bean>
>
> Where objectService is a bean defined within the Spring context.  In
> some quick tests, the session scope appears to be working, and JSF had
> no issue resolving the references to the beans configured within the
> spring context.
>
> It's not clear whether this is a Spring issue, a portlet bridge issue,
> or a LifeRay issue - any ideas on how to narrow this down will be
> greatly appreciated.
>
>
> Thanks,
>
> -Jan
>
>
> On Dec 14, 2007 7:13 AM, Jan Nielsen <jan...@gm...> wrote:
>   
>> We are building JSR-168 JSF portles for deployment into LifeRay Portal
>> with Spring and Hibernate. To hook into Spring we declare the
>> following in web.xml:
>>
>>     <listener>
>>         <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
>>     </listener>
>>
>>     <listener>
>>         <listener-class>org.springframework.web.context.request.RequestContextListener</listener-class>
>>     </listener>
>>
>> This is straight JSF - no Spring MVC or Spring Portlet MVC. Question
>> is: should the "scope" attribute on Spring context defined beans work
>> in this configuration; specifically, should the web scope values,
>> e.g., session, work in this configuration?
>>
>> More generally, is it possible to use JSF as the view technology for
>> Spring Portlet MVC? Can anyone provide a sample ala "petportal"? If it
>> is possible, what do you do with JSF's navigation-rules in the Spring
>> Portlet MVC model?
>>
>> Many thanks for any help you can provide. (I posed the 'use' question,
>> on the Spring user list a few days ago with no response...)
>>
>>
>> -Jan
>>
>>