Announcement Announcement Module
Collapse
No announcement yet.
OpenSessionInView and portlet support Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • OpenSessionInView and portlet support

    I have webflow portlet and I am getting issue with lazily loaded collections. How does OpenSessionInView interact with webflow. What do I need to do to get it to function. I tried following but it did not work.

    web.xml
    Code:
        <filter>
        	<filter-name>hibernateFilter</filter-name>
        	<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
      	</filter>
    
      	<filter-mapping> 
    		<filter-name>hibernateFilter</filter-name> 
    		<url-pattern>*.jsp</url-pattern>
      	</filter-mapping>
      	<filter-mapping> 
    		<filter-name>hibernateFilter</filter-name> 
    		<url-pattern>/*</url-pattern>
      	</filter-mapping>

  • #2
    Web flow doesn't interact with OpenSessionInView, or any servlet filter for that matter. Filters are much higher up above the web flow system.

    I don't have much experience with OSIV, but I expect the integration to be just like it would for Spring MVC. I'm not sure if the use of portlet makes any difference.

    Keith

    Comment


    • #3
      Here is something that works with Portlets....

      Here is a copy of OpenSessionInViewInterceptor that can work for both servlets and portlets. I suggest either refactoring the common code or using as is renaming it to the correct name.

      It can be used like

      Code:
        <bean id="portletModeControllerMapping"
              class="org.springframework.web.portlet.support.PortletModeControllerMapping">
          <property name="portletModeMap">
            <map>
              <entry key="view">
                <ref bean="viewModeFrontController" />
              </entry>
            </map>
          </property>
            <property name="interceptors"> 
               <list> 
                  <ref bean="openSessionInViewInterceptor"/>
               </list> 
            </property> 
      
        </bean>

      Here is the code

      Code:
      /**
       * Spring web HandlerInterceptor that binds a Hibernate Session to the thread for the
       * entire processing of the request. Intended for the "Open Session in View" pattern,
       * i.e. to allow for lazy loading in web views despite the original transactions
       * already being completed.
       *
       * <p>This interceptor works similar to the AOP HibernateInterceptor&#58; It just makes
       * Hibernate Sessions available via the thread. It is suitable for non-transactional
       * execution but also for middle tier transactions via HibernateTransactionManager
       * or JtaTransactionManager. In the latter case, Sessions pre-bound by this interceptor
       * will automatically be used for the transactions and flushed accordingly.
       *
       * <p>In contrast to OpenSessionInViewFilter, this interceptor is set up in a Spring
       * application context and can thus take advantage of bean wiring. It derives from
       * HibernateAccessor to inherit common Hibernate configuration properties.
       *
       * <p><b>WARNING&#58;</b> Applying this interceptor to existing logic can cause issues that
       * have not appeared before, through the use of a single Hibernate Session for the
       * processing of an entire request. In particular, the reassociation of persistent
       * objects with a Hibernate Session has to occur at the very beginning of request
       * processing, to avoid clashes will already loaded instances of the same objects.
       *
       * <p>Alternatively, turn this interceptor into deferred close mode, by specifying
       * "singleSession"="false"&#58; It will not use a single session per request then,
       * but rather let each data access operation or transaction use its own session
       * &#40;like without Open Session in View&#41;. Each of those sessions will be registered
       * for deferred close, though, actually processed at request completion.
       *
       * <p>A single session per request allows for most efficient first-level caching,
       * but can cause side effects, for example on saveOrUpdate or if continuing
       * after a rolled-back transaction. The deferred close strategy is as safe as
       * no Open Session in View in that respect, while still allowing for lazy loading
       * in views &#40;but not providing a first-level cache for the entire request&#41;.
       *
       * <p><b>NOTE</b>&#58; This interceptor will by default not flush the Hibernate session,
       * as it assumes to be used in combination with business layer transactions that care
       * for the flushing, or HibernateAccessors with flushMode FLUSH_EAGER. If you want this
       * interceptor to flush after the handler has been invoked but before view rendering,
       * set the flushMode of this interceptor to FLUSH_AUTO in such a scenario. Note that
       * the flushMode of this interceptor will just apply in single session mode!
       *
       * @author Juergen Hoeller
       * @since 1.2
       * @see #setSingleSession
       * @see #setFlushMode
       * @see OpenSessionInViewFilter
       * @see org.springframework.orm.hibernate3.HibernateInterceptor
       * @see org.springframework.orm.hibernate3.HibernateTransactionManager
       * @see org.springframework.orm.hibernate3.SessionFactoryUtils#getSession
       * @see org.springframework.transaction.support.TransactionSynchronizationManager
       */
      public class PortletOpenSessionInViewInterceptor extends HibernateAccessor implements HandlerInterceptor, PortletControllerInterceptor &#123;
      
      	/**
      	 * Suffix that gets appended to the SessionFactory toString representation
      	 * for the "participate in existing session handling" request attribute.
      	 * @see #getParticipateAttributeName
      	 */
      	public static final String PARTICIPATE_SUFFIX = ".PARTICIPATE";
      
      
      	private boolean singleSession = true;
      
      
      	/**
      	 * Create a new OpenSessionInViewInterceptor,
      	 * turning the default flushMode to FLUSH_NEVER.
      	 * @see #setFlushMode
      	 */
      	public PortletOpenSessionInViewInterceptor&#40;&#41; &#123;
      		setFlushMode&#40;FLUSH_NEVER&#41;;
      	&#125;
      
      	/**
      	 * Set whether to use a single session for each request. Default is true.
      	 * <p>If set to false, each data access operation or transaction will use
      	 * its own session &#40;like without Open Session in View&#41;. Each of those
      	 * sessions will be registered for deferred close, though, actually
      	 * processed at request completion.
      	 * @see SessionFactoryUtils#initDeferredClose
      	 * @see SessionFactoryUtils#processDeferredClose
      	 */
      	public void setSingleSession&#40;boolean singleSession&#41; &#123;
      		this.singleSession = singleSession;
      	&#125;
      
      	/**
      	 * Return whether to use a single session for each request.
      	 */
      	protected boolean isSingleSession&#40;&#41; &#123;
      		return singleSession;
      	&#125;
      
      
      	/**
      	 * Open a new Hibernate Session according to the settings of this HibernateAccessor
      	 * and binds in to the thread via TransactionSynchronizationManager.
      	 * @see org.springframework.orm.hibernate3.SessionFactoryUtils#getSession
      	 * @see org.springframework.transaction.support.TransactionSynchronizationManager
      	 */
      	public boolean preHandle&#40;HttpServletRequest request, HttpServletResponse response, Object handler&#41;
      	    throws DataAccessException &#123;
      
      		if &#40;&#40;isSingleSession&#40;&#41; && TransactionSynchronizationManager.hasResource&#40;getSessionFactory&#40;&#41;&#41;&#41; ||
      		    SessionFactoryUtils.isDeferredCloseActive&#40;getSessionFactory&#40;&#41;&#41;&#41; &#123;
      			// do not modify the Session&#58; just mark the request accordingly
      			String participateAttributeName = getParticipateAttributeName&#40;&#41;;
      			Integer count = &#40;Integer&#41; request.getAttribute&#40;participateAttributeName&#41;;
      			int newCount = &#40;count != null&#41; ? count.intValue&#40;&#41; + 1 &#58; 1;
      			request.setAttribute&#40;getParticipateAttributeName&#40;&#41;, new Integer&#40;newCount&#41;&#41;;
      		&#125;
      
      		else &#123;
      			if &#40;isSingleSession&#40;&#41;&#41; &#123;
      				// single session mode
      				logger.debug&#40;"Opening single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      				Session session = SessionFactoryUtils.getSession&#40;
      						getSessionFactory&#40;&#41;, getEntityInterceptor&#40;&#41;, getJdbcExceptionTranslator&#40;&#41;&#41;;
      				if &#40;getFlushMode&#40;&#41; == FLUSH_NEVER&#41; &#123;
      					session.setFlushMode&#40;FlushMode.NEVER&#41;;
      				&#125;
      				TransactionSynchronizationManager.bindResource&#40;getSessionFactory&#40;&#41;, new SessionHolder&#40;session&#41;&#41;;
      			&#125;
      			else &#123;
      				// deferred close mode
      				SessionFactoryUtils.initDeferredClose&#40;getSessionFactory&#40;&#41;&#41;;
      			&#125;
      		&#125;
      
      		return true;
      	&#125;
      
      	/**
      	 * Flush the Hibernate Session before view rendering, if necessary.
      	 * Note that this just applies in single session mode!
      	 * <p>The default is FLUSH_NEVER to avoid this extra flushing, assuming that
      	 * middle tier transactions have flushed their changes on commit.
      	 * @see #setFlushMode
      	 */
      	public void postHandle&#40;
      			HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView&#41;
      			throws DataAccessException &#123;
      
      		if &#40;isSingleSession&#40;&#41;&#41; &#123;
      			// only potentially flush in single session mode
      			SessionHolder sessionHolder =
      					&#40;SessionHolder&#41; TransactionSynchronizationManager.getResource&#40;getSessionFactory&#40;&#41;&#41;;
      			logger.debug&#40;"Flushing single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      			try &#123;
      				flushIfNecessary&#40;sessionHolder.getSession&#40;&#41;, false&#41;;
      			&#125;
      			catch &#40;HibernateException ex&#41; &#123;
      				throw convertHibernateAccessException&#40;ex&#41;;
      			&#125;
      		&#125;
      	&#125;
      
      	/**
      	 * Unbind the Hibernate Session from the thread and closes it &#40;in single session
      	 * mode&#41;, or process deferred close for all sessions that have been opened
      	 * during the current request &#40;in deferred close mode&#41;.
      	 * @see org.springframework.orm.hibernate3.SessionFactoryUtils#closeSessionIfNecessary
      	 * @see org.springframework.transaction.support.TransactionSynchronizationManager
      	 */
      	public void afterCompletion&#40;
      			HttpServletRequest request, HttpServletResponse response, Object handler, Exception ex&#41;
      			throws DataAccessException &#123;
      
      		String participateAttributeName = getParticipateAttributeName&#40;&#41;;
      		Integer count = &#40;Integer&#41; request.getAttribute&#40;participateAttributeName&#41;;
      		if &#40;count != null&#41; &#123;
      			// Do not modify the Session&#58; just clear the marker.
      			if &#40;count.intValue&#40;&#41; > 1&#41; &#123;
      				request.setAttribute&#40;participateAttributeName, new Integer&#40;count.intValue&#40;&#41; - 1&#41;&#41;;
      			&#125;
      			else &#123;
      				request.removeAttribute&#40;participateAttributeName&#41;;
      			&#125;
      		&#125;
      
      		else &#123;
      			if &#40;isSingleSession&#40;&#41;&#41; &#123;
      				// single session mode
      				SessionHolder sessionHolder =
      						&#40;SessionHolder&#41; TransactionSynchronizationManager.unbindResource&#40;getSessionFactory&#40;&#41;&#41;;
      				logger.debug&#40;"Closing single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      				SessionFactoryUtils.closeSessionIfNecessary&#40;sessionHolder.getSession&#40;&#41;, getSessionFactory&#40;&#41;&#41;;
      			&#125;
      			else &#123;
      				// deferred close mode
      				SessionFactoryUtils.processDeferredClose&#40;getSessionFactory&#40;&#41;&#41;;
      			&#125;
      		&#125;
      	&#125;
      
      	/**
      	 * Return the name of the request attribute that identifies that a request is
      	 * already filtered. Default implementation takes the toString representation
      	 * of the SessionFactory instance and appends ".PARTICIPATE".
      	 * @see #PARTICIPATE_SUFFIX
      	 */
      	protected String getParticipateAttributeName&#40;&#41; &#123;
      		return getSessionFactory&#40;&#41;.toString&#40;&#41; + PARTICIPATE_SUFFIX;
      	&#125;
      
      	/* &#40;non-Javadoc&#41;
      	 * @see org.springframework.web.portlet.PortletControllerInterceptor#preController&#40;javax.portlet.PortletRequest, javax.portlet.PortletResponse, org.springframework.web.portlet.support.PortletController&#41;
      	 */
      	public boolean preController&#40;PortletRequest request, PortletResponse response, PortletController handler&#41; throws Exception &#123;
      		if &#40;&#40;isSingleSession&#40;&#41; && TransactionSynchronizationManager.hasResource&#40;getSessionFactory&#40;&#41;&#41;&#41; ||
      			    SessionFactoryUtils.isDeferredCloseActive&#40;getSessionFactory&#40;&#41;&#41;&#41; &#123;
      				// do not modify the Session&#58; just mark the request accordingly
      				String participateAttributeName = getParticipateAttributeName&#40;&#41;;
      				Integer count = &#40;Integer&#41; request.getAttribute&#40;participateAttributeName&#41;;
      				int newCount = &#40;count != null&#41; ? count.intValue&#40;&#41; + 1 &#58; 1;
      				request.setAttribute&#40;getParticipateAttributeName&#40;&#41;, new Integer&#40;newCount&#41;&#41;;
      			&#125;
      
      			else &#123;
      				if &#40;isSingleSession&#40;&#41;&#41; &#123;
      					// single session mode
      					logger.debug&#40;"Opening single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      					Session session = SessionFactoryUtils.getSession&#40;
      							getSessionFactory&#40;&#41;, getEntityInterceptor&#40;&#41;, getJdbcExceptionTranslator&#40;&#41;&#41;;
      					if &#40;getFlushMode&#40;&#41; == FLUSH_NEVER&#41; &#123;
      						session.setFlushMode&#40;FlushMode.NEVER&#41;;
      					&#125;
      					TransactionSynchronizationManager.bindResource&#40;getSessionFactory&#40;&#41;, new SessionHolder&#40;session&#41;&#41;;
      				&#125;
      				else &#123;
      					// deferred close mode
      					SessionFactoryUtils.initDeferredClose&#40;getSessionFactory&#40;&#41;&#41;;
      				&#125;
      			&#125;
      
      			return true;
      	&#125;
      
      	/* &#40;non-Javadoc&#41;
      	 * @see org.springframework.web.portlet.PortletControllerInterceptor#postController&#40;javax.portlet.RenderRequest, javax.portlet.RenderResponse, org.springframework.web.portlet.support.PortletController, org.springframework.web.servlet.ModelAndView&#41;
      	 */
      	public void postController&#40;RenderRequest request, RenderResponse response, PortletController handler, ModelAndView modelAndView&#41; throws Exception &#123;
      
      		if &#40;isSingleSession&#40;&#41;&#41; &#123;
      			// only potentially flush in single session mode
      			SessionHolder sessionHolder =
      					&#40;SessionHolder&#41; TransactionSynchronizationManager.getResource&#40;getSessionFactory&#40;&#41;&#41;;
      			logger.debug&#40;"Flushing single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      			try &#123;
      				flushIfNecessary&#40;sessionHolder.getSession&#40;&#41;, false&#41;;
      			&#125;
      			catch &#40;HibernateException ex&#41; &#123;
      				throw convertHibernateAccessException&#40;ex&#41;;
      			&#125;
      		&#125;
      		
      	&#125;
      
      	/* &#40;non-Javadoc&#41;
      	 * @see org.springframework.web.portlet.PortletControllerInterceptor#afterCompletion&#40;javax.portlet.PortletRequest, javax.portlet.PortletResponse, org.springframework.web.portlet.support.PortletController, java.lang.Exception&#41;
      	 */
      	public void afterCompletion&#40;PortletRequest request, PortletResponse response, PortletController handler, Exception ex&#41; throws Exception &#123;
      		String participateAttributeName = getParticipateAttributeName&#40;&#41;;
      		Integer count = &#40;Integer&#41; request.getAttribute&#40;participateAttributeName&#41;;
      		if &#40;count != null&#41; &#123;
      			// Do not modify the Session&#58; just clear the marker.
      			if &#40;count.intValue&#40;&#41; > 1&#41; &#123;
      				request.setAttribute&#40;participateAttributeName, new Integer&#40;count.intValue&#40;&#41; - 1&#41;&#41;;
      			&#125;
      			else &#123;
      				request.removeAttribute&#40;participateAttributeName&#41;;
      			&#125;
      		&#125;
      
      		else &#123;
      			if &#40;isSingleSession&#40;&#41;&#41; &#123;
      				// single session mode
      				SessionHolder sessionHolder =
      						&#40;SessionHolder&#41; TransactionSynchronizationManager.unbindResource&#40;getSessionFactory&#40;&#41;&#41;;
      				logger.debug&#40;"Closing single Hibernate session in OpenSessionInViewInterceptor"&#41;;
      				SessionFactoryUtils.closeSessionIfNecessary&#40;sessionHolder.getSession&#40;&#41;, getSessionFactory&#40;&#41;&#41;;
      			&#125;
      			else &#123;
      				// deferred close mode
      				SessionFactoryUtils.processDeferredClose&#40;getSessionFactory&#40;&#41;&#41;;
      			&#125;
      		&#125;
      		
      	&#125;
      
      &#125;

      Comment


      • #4
        I'll post this to the Spring developer list.

        Erwin

        Comment


        • #5
          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

          Comment


          • #6
            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.

            Comment


            • #7
              Couldn't you pass hibernate session from action to render

              Couldn't you pass hibernate session from action to render through portlet session? FYI currenlty the interceptor appears to work for Jetspeed2 and Liferay so either they are both not doing parallel or there is something else going on. It seems then what you are saying is PortletModeControllerMapping will not completely support interceptors in the even the renders occur on different threads...

              Comment


              • #8
                I haven't said " PortletModeControllerMapping will not completely ...", in my previous reply I only commented about Filter not about Interceptor :wink: It could be a way to implement this feature.

                But, note that interceptor flow are executed completely in the action request (preController, postController and afterCompletion) and in the render request too (idem).

                Comment


                • #9
                  ??

                  SO how does hibernate session get passed between action and render

                  Comment


                  • #10
                    I think Mr. Ruiz's point is that the action request and the render request are completely separate from each other and have their own session.

                    The action phase is responsible for making any changes required by request, like making updates to a database, for example. The action phase is executed only once and does not generate a model and view -- it is only responsible for performing any back-end changes that are needed.

                    The render phase on the other hand, should engage only in "read-only" activity since the portal may execute it repeatedly any number of times. This is the reason for the separation -- so that changes can be made just once but results can be displayed over and over again.

                    This is important if you think about how portlets operate. Imagine if you have an inventory portlet where you make some changes to inventory and the result is that it shows the current inventory levels. You want it to query the inventory again on each render so that you are always seeing the current inventory level, not just the level it was at during your last change.

                    Comment


                    • #11
                      We solved this issue in a slightly different way. 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.

                      Code:
                      /*
                      * Copyright 2002-2004 the original author or authors.
                      *
                      * Licensed under the Apache License, Version 2.0 &#40;the "License"&#41;;
                      * you may not use this file except in compliance with the License.
                      * You may obtain a copy of the License at
                      *
                      *      http&#58;//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&#58; 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 &#123;
                      
                         public boolean preController&#40;PortletRequest request, PortletResponse response,
                                 PortletController handler&#41; throws Exception &#123;
                             if &#40;request instanceof HttpServletRequest &&
                                     response instanceof HttpServletResponse&#41;
                                 return super.preHandle&#40;&#40;HttpServletRequest&#41;request, &#40;HttpServletResponse&#41;response,
                                         &#40;Object&#41;handler&#41;;
                             return false;
                         &#125;
                      
                         public void postController&#40;RenderRequest request, RenderResponse response,
                                 PortletController handler, ModelAndView modelAndView&#41; throws Exception &#123;
                             if &#40;request instanceof HttpServletRequest &&
                                     response instanceof HttpServletResponse&#41;
                                 super.postHandle&#40;&#40;HttpServletRequest&#41;request, &#40;HttpServletResponse&#41;response,
                                         &#40;Object&#41;handler, modelAndView&#41;;
                         &#125;
                      
                         public void afterCompletion&#40;PortletRequest request, PortletResponse response,
                                 PortletController handler, Exception ex&#41; throws Exception &#123;
                             if &#40;request instanceof HttpServletRequest &&
                                     response instanceof HttpServletResponse&#41;
                                 super.afterCompletion&#40;&#40;HttpServletRequest&#41;request, &#40;HttpServletResponse&#41;response,
                                         &#40;Object&#41;handler, ex&#41;;
                         &#125;
                      
                      &#125;

                      Comment


                      • #12
                        Great....

                        Does this also have implications to remove code duplication noted here

                        http://opensource.atlassian.com/conf...ign+discussion

                        I'd also appreciate your comments here
                        http://forum.springframework.org/viewtopic.php?t=5462

                        Comment


                        • #13
                          William Thompson implemented most of Juergen's suggestions a long time ago. The biggest concern was the duplication of the view code, and this was eliminated with the use of the ViewRendererServlet class.

                          The thing I don't like about what we've done with our curren OSIV class is that we are relying on an implemention choice made by most of the portal vendors but not something that is in the spec. Probably the right thing to do is have a separate OSIV calss just for the portlets that can stand alone, but what we are using now works in every portal we are dealing with.

                          Comment


                          • #14
                            How do you plan to support hibernate3

                            How do you plan to support hibernate3 in package structure?

                            BTW I can confirm it works in jetspeed2

                            Comment


                            • #15
                              I dug out the list of portals that we checked for this behavior a few months ago. Here were the results:

                              Pluto/Jetspeed2 - yes
                              uPortal - yes
                              Gridsphere - yes
                              Eco - yes
                              Liferay - no

                              So, there is at least one open source portal, Liferay, where this will not work. So this is definitely not a good permanent solution. I have no idea about any of the commercial portals since I cannot look at their source code and don't have the time to obtain them and test them.

                              I haven't thought about Hibernate 3 yet -- been to busy with other portlet issues for now. Any one else have any thoughts?

                              Comment

                              Working...
                              X