springframework-developer

[Springframework-developer] OpenSessionInView and portlet support

[Erwin V. <erw...@er...>]

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... 

Re: [Springframework-developer] OpenSessionInView and portlet support

[Juergen H. <ju...@in...>]

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

Re: [Springframework-developer] OpenSessionInView and portlet support

[J. E. R. <er...@di...>]

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
>
>  
>


-- 
J.Enrique Ruiz
Director de I+D+I - DiSiD S.L.L. (http://www.disid.com)
Tel +34 655 407 965
Email: er...@di...

[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
>>
>>  
>>
>
>

Re: [Springframework-developer] Re: OpenSessionInView and portlet support

[Rob B. <cro...@ya...>]

Why not refactor the OpenSessionInViewInterceptor  to
a new class called CommonOpenSessionInViewInterceptor
and have it operate on a set of new interfaces called
CommonRequest and CommonResponse.

Then have two separate implementations.  One is called
OpenSessionInViewInterceptor (to replace the original
and remain backward compatible with existing code). 
The other is PortletOpenSessionInViewInterceptor. 
These classes can then wrap (not extend) the
CommonOpenSessionInViewInterceptor ala the adapter
pattern.  These classes each have inner classes that
implement the web/portlet version of CommonRequest &
CommonResponse, and pass these to the
CommonOpenSessionInViewInterceptor.

End result, no code duplication, Spring web MVC is not
tied to Portlet MVC, and you no longer have to hope
that PortletRequest is really a HttpServletRequest.

Just an idea.
Rob


--- John Lewis <jl...@ar...> wrote:

> 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
> >>
> >>  
> >>
> >
> >
> 
> 
> 
>
-------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space
> Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
>
http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
>
https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 



		
__________________________________ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

[Springframework-developer] Re: OpenSessionInView and portlet support

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

I agree that a refactoring of the code is the best permanent solution. 
Hopefully we can take this track when we really start working on getting 
the Portlet MVC framework integrated into Spring.

Rob Butler wrote:
> Why not refactor the OpenSessionInViewInterceptor  to
> a new class called CommonOpenSessionInViewInterceptor
> and have it operate on a set of new interfaces called
> CommonRequest and CommonResponse.
> 
> Then have two separate implementations.  One is called
> OpenSessionInViewInterceptor (to replace the original
> and remain backward compatible with existing code). 
> The other is PortletOpenSessionInViewInterceptor. 
> These classes can then wrap (not extend) the
> CommonOpenSessionInViewInterceptor ala the adapter
> pattern.  These classes each have inner classes that
> implement the web/portlet version of CommonRequest &
> CommonResponse, and pass these to the
> CommonOpenSessionInViewInterceptor.
> 
> End result, no code duplication, Spring web MVC is not
> tied to Portlet MVC, and you no longer have to hope
> that PortletRequest is really a HttpServletRequest.
> 
> Just an idea.
> Rob
> 
> 
> --- John Lewis <jl...@ar...> wrote:
> 
> 
>>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
> 
>>>> 
>>>>
>>>
>>>
>>
>>
>>
> -------------------------------------------------------
> 
>>This SF.Net email is sponsored by Oracle Space
>>Sweepstakes
>>Want to be the first software developer in space?
>>Enter now for the Oracle Space Sweepstakes!
>>
> 
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click
> 
>>_______________________________________________
>>Springframework-developer mailing list
>>Spr...@li...
>>
> 
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
> 
> 
> 
> 
> 		
> __________________________________ 
> Yahoo! Mail Mobile 
> Take Yahoo! Mail with you! Check email on your mobile phone. 
> http://mobile.yahoo.com/learn/mail 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click

Re: [Springframework-developer] Re: OpenSessionInView and portlet support

[J.Enrique Ruiz-V. <er...@di...>]

+1 for Portlet MVC integration

> I agree that a refactoring of the code is the best permanent solution. 
> Hopefully we can take this track when we really start working on 
> getting the Portlet MVC framework integrated into Spring.
>
> Rob Butler wrote:
>
>> Why not refactor the OpenSessionInViewInterceptor  to
>> a new class called CommonOpenSessionInViewInterceptor
>> and have it operate on a set of new interfaces called
>> CommonRequest and CommonResponse.
>>
>> Then have two separate implementations.  One is called
>> OpenSessionInViewInterceptor (to replace the original
>> and remain backward compatible with existing code). The other is 
>> PortletOpenSessionInViewInterceptor. These classes can then wrap (not 
>> extend) the
>> CommonOpenSessionInViewInterceptor ala the adapter
>> pattern.  These classes each have inner classes that
>> implement the web/portlet version of CommonRequest &
>> CommonResponse, and pass these to the
>> CommonOpenSessionInViewInterceptor.
>>
>> End result, no code duplication, Spring web MVC is not
>> tied to Portlet MVC, and you no longer have to hope
>> that PortletRequest is really a HttpServletRequest.
>>
>> Just an idea.
>> Rob
>

-- 
J.Enrique Ruiz Valenciano
CIO, DiSiD S.L.L. (http://www.disid.com)
Email: er...@di...

[Springframework-developer] Support for state/controller chaining in Portlets? (not quite webflow)

[Tim K. <tim...@vi...>]

Hi everyone,

I'm just throwing this out here to see what other people have to say.  I can
see from the list that there are a few developers actively working on portal
solutions using Spring MVC.  We are starting on our first project using this
as well, and one of the issues I'm trying to figure out now is the matter of
maintaining state in a portlet.  

In a typical CRUD example, if we have a portlet to display, edit and maange
information about a certain object, like a Book. We'd have view, edit and
delete functionality for example. 

In a typical non-portlet webapp, we could easily split those up across
different servlets for fine-grained areas of responsibility.  

But it's not as simple with portlets, because there are limitations on what
can be done, and essentially, all requests would need to go thru a single
portlet configuration.  

So, it no longer become sufficient to configure a simple portlet controller
for a portlet.  There needs to be a way to maintain state and to delegate
the request/response process to different types of controllers depending on
the state.  Like a View page would need to go thru a derivation of
BaseCommandController, an Edit page would go thru SimpleFormController. 

And not to mention adding yet another dimension when considering portlet
modes as well!

This article at IBM Developerworks pretty much covers the same issue I am
bringing up:

http://www-106.ibm.com/developerworks/websphere/library/techarticles/0312_ha
nis/hanis1.html

I did look at Spring's WebFlow a few days ago to see if it could address our
issue, but in the Webflow FAQ, it pretty much states that WebFlow should not
be used in cases where the user will be using back-button, or indeterminate
actions not within a strict flow.  

So that kinda leaves me back at square one.  After some discussion with my
co-worker, I would imagine that this is a common problem for any Spring
portlet developer creating more than just simple portlet functionality.  And
that as Spring portlet support matures, this will be a more common issue for
everyone.  Hence this email to the list.  

I'm now wondering how some of you have addressed this problem, and whether
there is a need for Spring's portlet support, to be in Spring 1.3 to include
some way to configure and facilitate a state process, maybe even based on
WebFlow's state machine - although I have only given WebFlow's state
functionality a brief look.

Thanks in advance,

-tim

Re: [Springframework-developer] Support for state/controller chaining in Portlets? (not quite webflow)

[J.Enrique Ruiz-V. <er...@di...>]

Hi Tim,

It could take to long time to explain you how we work with portlets, but 
basically, we use View mode for read-only operations and Edit mode for 
write operations. Before using Spring Webflow we were using one 
Controller for each mode, in Edit mode we were using our porting of 
MultiActionController to manage each update action. Now with Spring 
Webflow we have one Controller for each portlet, one flow for each 
portlet mode and we have one SWF-Action for each read or write action.

I hope this message can help you.

>Hi everyone,
>
>I'm just throwing this out here to see what other people have to say.  I can
>see from the list that there are a few developers actively working on portal
>solutions using Spring MVC.  We are starting on our first project using this
>as well, and one of the issues I'm trying to figure out now is the matter of
>maintaining state in a portlet.  
>
>In a typical CRUD example, if we have a portlet to display, edit and maange
>information about a certain object, like a Book. We'd have view, edit and
>delete functionality for example. 
>
>In a typical non-portlet webapp, we could easily split those up across
>different servlets for fine-grained areas of responsibility.  
>
>But it's not as simple with portlets, because there are limitations on what
>can be done, and essentially, all requests would need to go thru a single
>portlet configuration.  
>
>So, it no longer become sufficient to configure a simple portlet controller
>for a portlet.  There needs to be a way to maintain state and to delegate
>the request/response process to different types of controllers depending on
>the state.  Like a View page would need to go thru a derivation of
>BaseCommandController, an Edit page would go thru SimpleFormController. 
>
>And not to mention adding yet another dimension when considering portlet
>modes as well!
>
>This article at IBM Developerworks pretty much covers the same issue I am
>bringing up:
>
>http://www-106.ibm.com/developerworks/websphere/library/techarticles/0312_ha
>nis/hanis1.html
>
>I did look at Spring's WebFlow a few days ago to see if it could address our
>issue, but in the Webflow FAQ, it pretty much states that WebFlow should not
>be used in cases where the user will be using back-button, or indeterminate
>actions not within a strict flow.  
>
>So that kinda leaves me back at square one.  After some discussion with my
>co-worker, I would imagine that this is a common problem for any Spring
>portlet developer creating more than just simple portlet functionality.  And
>that as Spring portlet support matures, this will be a more common issue for
>everyone.  Hence this email to the list.  
>
>I'm now wondering how some of you have addressed this problem, and whether
>there is a need for Spring's portlet support, to be in Spring 1.3 to include
>some way to configure and facilitate a state process, maybe even based on
>WebFlow's state machine - although I have only given WebFlow's state
>functionality a brief look.
>
>Thanks in advance,
>
>-tim
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by Oracle Space Sweepstakes
>Want to be the first software developer in space?
>Enter now for the Oracle Space Sweepstakes!
>http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>  
>

-- 
J.Enrique Ruiz-Valenciano
CIO, DiSiD S.L.L. (http://www.disid.com)
Phone: +34.655407965
Email: er...@di...

Re: [Springframework-developer] Support for state/controller chaining in Portlets? (not quite webflow)

[Steven D. <ste...@gm...>]

Regarding the WebFlow FAQ entry, this should not be a limitation for
CRUD applications. For example, you should never call the remove
action before you have displayed the related record which is by itself
an example of a workflow. The same for detail screens, you should
first pass through a table view or another detail screen.

I'm not sure about the back button, maybe somebody from the WebFlow
crew could comment on that.

On 5/17/05, Tim Kettering <tim...@vi...> wrote:
>=20
> Hi everyone,
>=20
> I'm just throwing this out here to see what other people have to say.  I =
can
> see from the list that there are a few developers actively working on por=
tal
> solutions using Spring MVC.  We are starting on our first project using t=
his
> as well, and one of the issues I'm trying to figure out now is the matter=
 of
> maintaining state in a portlet.
>=20
> In a typical CRUD example, if we have a portlet to display, edit and maan=
ge
> information about a certain object, like a Book. We'd have view, edit and
> delete functionality for example.
>=20
> In a typical non-portlet webapp, we could easily split those up across
> different servlets for fine-grained areas of responsibility.
>=20
> But it's not as simple with portlets, because there are limitations on wh=
at
> can be done, and essentially, all requests would need to go thru a single
> portlet configuration.
>=20
> So, it no longer become sufficient to configure a simple portlet controll=
er
> for a portlet.  There needs to be a way to maintain state and to delegate
> the request/response process to different types of controllers depending =
on
> the state.  Like a View page would need to go thru a derivation of
> BaseCommandController, an Edit page would go thru SimpleFormController.
>=20
> And not to mention adding yet another dimension when considering portlet
> modes as well!
>=20
> This article at IBM Developerworks pretty much covers the same issue I am
> bringing up:
>=20
> http://www-106.ibm.com/developerworks/websphere/library/techarticles/0312=
_ha
> nis/hanis1.html
>=20
> I did look at Spring's WebFlow a few days ago to see if it could address =
our
> issue, but in the Webflow FAQ, it pretty much states that WebFlow should =
not
> be used in cases where the user will be using back-button, or indetermina=
te
> actions not within a strict flow.
>=20
> So that kinda leaves me back at square one.  After some discussion with m=
y
> co-worker, I would imagine that this is a common problem for any Spring
> portlet developer creating more than just simple portlet functionality.  =
And
> that as Spring portlet support matures, this will be a more common issue =
for
> everyone.  Hence this email to the list.
>=20
> I'm now wondering how some of you have addressed this problem, and whethe=
r
> there is a need for Spring's portlet support, to be in Spring 1.3 to incl=
ude
> some way to configure and facilitate a state process, maybe even based on
> WebFlow's state machine - although I have only given WebFlow's state
> functionality a brief look.
>=20
> Thanks in advance,
>=20
> -tim
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] Support for state/controller chaining in Portlets? (not quite webflow)

[Erwin V. <erw...@er...>]

Regarding the back button: if your requirements mandate that the user be=20
able to use the back & refresh buttons offered by the browser, SWF is=20
basically out unless you are prepared to go for a continuations based flo=
w=20
storage strategy (e.g. PortletSessionContinuationFlowExecutionStorage). O=
n=20
the other hand, if it is acceptable that use of the back/refresh button=20
leads to an error page that allows the user to restart the flow, you can =
use=20
SWF no problem.


Erwin Vervaet
erw...@er...
----- Original Message -----=20
From: "Steven Devijver" <ste...@gm...>
To: <spr...@li...>
Sent: Tuesday, May 24, 2005 9:18 AM
Subject: Re: [Springframework-developer] Support for state/controller=20
chaining in Portlets? (not quite webflow)


Regarding the WebFlow FAQ entry, this should not be a limitation for
CRUD applications. For example, you should never call the remove
action before you have displayed the related record which is by itself
an example of a workflow. The same for detail screens, you should
first pass through a table view or another detail screen.

I'm not sure about the back button, maybe somebody from the WebFlow
crew could comment on that.

On 5/17/05, Tim Kettering <tim...@vi...> wrote:
>
> Hi everyone,
>
> I'm just throwing this out here to see what other people have to say.  =
I=20
> can
> see from the list that there are a few developers actively working on=20
> portal
> solutions using Spring MVC.  We are starting on our first project using=
=20
> this
> as well, and one of the issues I'm trying to figure out now is the matt=
er=20
> of
> maintaining state in a portlet.
>
> In a typical CRUD example, if we have a portlet to display, edit and=20
> maange
> information about a certain object, like a Book. We'd have view, edit a=
nd
> delete functionality for example.
>
> In a typical non-portlet webapp, we could easily split those up across
> different servlets for fine-grained areas of responsibility.
>
> But it's not as simple with portlets, because there are limitations on=20
> what
> can be done, and essentially, all requests would need to go thru a sing=
le
> portlet configuration.
>
> So, it no longer become sufficient to configure a simple portlet=20
> controller
> for a portlet.  There needs to be a way to maintain state and to delega=
te
> the request/response process to different types of controllers dependin=
g=20
> on
> the state.  Like a View page would need to go thru a derivation of
> BaseCommandController, an Edit page would go thru SimpleFormController.
>
> And not to mention adding yet another dimension when considering portle=
t
> modes as well!
>
> This article at IBM Developerworks pretty much covers the same issue I =
am
> bringing up:
>
> http://www-106.ibm.com/developerworks/websphere/library/techarticles/03=
12_ha
> nis/hanis1.html
>
> I did look at Spring's WebFlow a few days ago to see if it could addres=
s=20
> our
> issue, but in the Webflow FAQ, it pretty much states that WebFlow shoul=
d=20
> not
> be used in cases where the user will be using back-button, or=20
> indeterminate
> actions not within a strict flow.
>
> So that kinda leaves me back at square one.  After some discussion with=
 my
> co-worker, I would imagine that this is a common problem for any Spring
> portlet developer creating more than just simple portlet functionality.=
=20
> And
> that as Spring portlet support matures, this will be a more common issu=
e=20
> for
> everyone.  Hence this email to the list.
>
> I'm now wondering how some of you have addressed this problem, and whet=
her
> there is a need for Spring's portlet support, to be in Spring 1.3 to=20
> include
> some way to configure and facilitate a state process, maybe even based =
on
> WebFlow's state machine - although I have only given WebFlow's state
> functionality a brief look.
>
> Thanks in advance,
>
> -tim
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by Oracle Space Sweepstakes
> Want to be the first software developer in space?
> Enter now for the Oracle Space Sweepstakes!
> http://ads.osdn.com/?ad_id=3D7412&alloc_id=3D16344&op=3Dclick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>


--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart


-------------------------------------------------------
This SF.Net email is sponsored by Oracle Space Sweepstakes
Want to be the first software developer in space?
Enter now for the Oracle Space Sweepstakes!
http://ads.osdn.com/?ad_idt12&alloc_id=16344&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer