[Springframework-developer] Re: OpenSessionInView and portlet support

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

Hi.  I just ran across this thread and thought I would mention our 
current solution to this issue.

As discussed, filters do not apply to portlets, nor should they since 
they are for filtering servlet requests and portlets are really a 
different animal.  However, the use of Spring interceptors works 
perfectly for portlets and is the right way to go.

For now, we have taken advantage of a fact that I believe is true for 
most/all JSR-168 portal platforms: the PortletRequest and 
PortletResponse objects are also the HttpServletRequest and 
HttpServletResponse objects.  Because this is true, we are just 
delegating to the existing OpenSessionInViewInterceptor class.  This is 
not required by the JSR-168 spec and so is not guaranteed to work, but 
it has been true on all the platforms I have checked so far.

Below are the contents of the class we are currently using.  I hope you 
find this helpful.  I'd love to hear feedback from others on this.  Has 
anyone been using a portal platform where this will not work?

I'd like to include this class in the Portlet MVC framework in the 
sandbox once we can get some motion going with that again.

-- John Lewis



/*
 * Copyright 2002-2004 the original author or authors.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

package org.springframework.web.portlet.support.hibernate;

import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.springframework.web.portlet.PortletControllerInterceptor;
import org.springframework.web.portlet.support.PortletController;
import org.springframework.web.servlet.ModelAndView;

/**
 * <p>PortletControllerInteceptor that provides access to an open
 * Hibernate session in the view.</p>
 *
 * <p>This implementation delgates to
 * 
<code>org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor</code>,
 * but this only works if the <code>PortletRequest</code> and 
<code>PortletReponse</code> objects
 * involved are also instances of <code>HttpServletRequest</code> and 
<code>HttpServletReponse</code>.
 * While most portal providers do implement their classes this way, it 
is not
 * part of the JSR-168 spec and is not guaranteed to work.  Be sure to test
 * this with any target portal platforms before comitting to usage of this
 * class.</p>
 *
 * <p>TODO: Reimplement this class as a standalone Interceptor without 
the above limitation.</p>
 *
 * @author John Lewis
 * @see 
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
 */
public class OpenSessionInViewInterceptor extends
        
org.springframework.orm.hibernate.support.OpenSessionInViewInterceptor
        implements PortletControllerInterceptor {

    public boolean preController(PortletRequest request, PortletResponse 
response,
            PortletController handler) throws Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            return super.preHandle((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler);
        return false;
    }

    public void postController(RenderRequest request, RenderResponse 
response,
            PortletController handler, ModelAndView modelAndView) throws 
Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            super.postHandle((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler, modelAndView);
    }

    public void afterCompletion(PortletRequest request, PortletResponse 
response,
            PortletController handler, Exception ex) throws Exception {
        if (request instanceof HttpServletRequest &&
                response instanceof HttpServletResponse)
            super.afterCompletion((HttpServletRequest)request, 
(HttpServletResponse)response,
                    (Object)handler, ex);
    }

}







J. Enrique Ruiz wrote:

> Hi,
>
> A Portlet is not a Servlet, a set of portlets are invoked directly by 
> the portlet-container in one client request.
>
> The portlet spec says: "If the client request is triggered by an 
> action URL, the portal/portlet-container must first trigger the action 
> request by invoking the processAction method of the targeted portlet. 
> The portal/portlet-container must wait until the action request 
> finishes. Then, the portal/portlet-container must trigger the render 
> request by invoking the render method for all the portlets in the 
> portal page with the possible exception of portlets for which their 
> content is being cached. The render requests may be executed 
> sequentially or in parallel without any guaranteed order."
>
> Note that 'the render request may be executed IN PARALLEL', as I 
> understand it, each render request could be executed on different 
> threads. I think this feature advises against the use of 
> OpenSessionInViewFilter class with portlets.
>
>> Well, if OpenSessionInViewFilter doesn't kick in for portlets, no other
>> filter will kick in with portlets either. Isn't there maybe some general
>> issue hiding there?
>>
>> Of course we can provide an OpenSessionInViewInterceptor for 
>> portlets, but
>> I'm not sure whether that's actually a good fit there. The Portlet 
>> request
>> flow with separate handle and render callbacks makes this less 
>> compelling.
>>
>> What we certainly can't do is let the existing 
>> OpenSessionInViewInterceptor
>> implement some PortletControllerInterceptor interface. That would force
>> every Servlet user to have the portlet.jar on the classpath.
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On Behalf
>> Of Erwin Vervaet
>> Sent: Tuesday, April 19, 2005 9:26 PM
>> To: spr...@li...
>> Subject: [Springframework-developer] OpenSessionInView and portlet
>> support
>>
>>
>> Apparently the existing OSIV filter does not work with portlets:
>>
>> http://forum.springframework.org/viewtopic.php?t=4907
>>
>> I guess we should tackle this issue when doing the Portlet support 
>> for 1.3.
>> There is no PortletMVC category in JIRA so I'm not sure where to file 
>> it...
>> Any input from the Porlet people?
>>
>> Erwin Vervaet
>> erw...@er...
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime info,
>> new features, or free trial, at: 
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime info,
>> new features, or free trial, at: 
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>  
>>
>
>