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

  • OpenSessionInViewInterceptor

    Hi,

    Has anyone used this interceptor in portlets to keep the hibernate session open in jsp for lazy loading? If so, how do you keep the session opened in the action phase available in the render phase of the portlet? Any suggestions will be greatly appreciated.

    Thanks,

    anicad

  • #2
    You need to set the HandlerMapping's "applyWebRequestInterceptorsToRenderPhaseOnly" flag to "false" on the bean. Take a look at the WebRequestInterceptor and AbstractHandlerMapping javadocs for more info on this.

    I'll caution you that this is generally a bad idea. Since your render request may run multiple times, it is not a good idea to depend on an open session from the action phase because it will only be there the first time. If you are making changes to a database object in the action phase, you should reload the object from database during the render phase. Not only will this make sure that it works for multiple renders, it will also show the most current data (in case someone else changes it later).

    Hope that helps!

    Comment


    • #3
      Thank you for the information, John. What is the best way to pass parameters from the action phase to the render phase of a portlet? I know you can pass around string types, but what about more complex objects? I appreciate your help.

      Thanks,

      anicad

      Comment


      • #4
        renderParameters are limited to Strings (as you mention) and should also be kept to a minimum. Some portal implementations embed all the render parameters into the URL, so if you have a lot of them or the values are long, it is easy to blow up the maximum URL size. Remember that there can be multiple portlets on the screen at the same time, which makes the problem even bigger. So at most, only use a few renderParameters with short values in them.

        In Portlet 1.0, the only other mechanism for passing data from Action to Render is the session.

        In Portlet 2.0, you get access to Request Attributes, which can be complete objects passed from Action to Render.

        Hope that helps!

        John

        Comment


        • #5
          Thanks, again, John. Spring Portlet MVC does not support the Portlet 2.0 api yet, does it?

          Also, one more question regarding keeping the hibernate session from the action phase open into the render phase. Suppose I am performing a search based on certain criteria selected or entered. How would I perform the search in my action phase and pass the results returned to the render phase for display? Right now I am using the session, but I wanted to know if you had any other suggestions or what is best practice. The thing about using the session is that it has to be cleaned up to avoid pollution. I appreciate your help.

          Thanks,

          anicad

          Comment


          • #6
            Spring doesn't provide special support for Portlet 2.0 yet, but if your portlet container has implemented 2.0, you should still be able to use Spring MVC and you should be able to use Portlet 2.0 features directly. Check you Portal/Portlet container to see if it supports JSR 286 (Portlet 2.0) yet. There will be support for Portlet 2.0 in Spring 3.0.

            If you are doing a search, you don't necessarily need to do it in the Action Phase at all. You can just do it directly in the Render Phase. You only need to use Action when you are making a change to the state of the overall system. In fact, performing the Search in the Render phase is preferrable since it means that on a re-render, the search will be rerun and the most current results will be displayed -- this is one of the reasons for the split in phases to begin with. If you are using the Action phase because you are using a form controller and that's how it handles submits, then simply capture the search criteria and pass them to the render phase (either as render attributes or via the session) and then use them in the render to do the search.

            Session pollution is a genuine problem with portlets. We frequently need to pass objects to the render, but since the render can be performed many times, we can't remove the objects from the session. I've not seen a good general solution to this issue, mainly because it's hard to know when you are done rendering a given request and moved on to a new one. You would need some kind of object registry and an interceptor to go with it, that would remove objects when you know you are done with them.

            Hope that helps!

            Comment


            • #7
              Hi John,

              Thank you for all your helpful responses. I have a few more questions regarding the integration of Spring WebFlow and MVC for portlets. Would session clean up be automatically taken care of, if I switch my application to use SWF? Also, how do I switch my application that currently uses the spring portlet mvc framework to use SWF? I read through the SWF documentation and from my understanding, SWF replaces the Controller in Portlet MVC. However, I don't really understand how to make the switch. Would it only be configuration changes or does it require code change? I greatly appreciate your help.

              Thanks,

              anicad

              Comment


              • #8
                Hi Anicad,

                I have just one question if you have implemented the search. Do you able to get right result if you use browser's back button and change the search critriea?

                Meanly Are you able to get search query string in the action or action phase is called in above case.

                Thanks
                Gurmeet

                Comment


                • #9
                  I'm not much of a Web Flow expert, so I doubt I can help much with your last question.

                  Web Flow does generally handle back button issues quite well, so might be a good approach assuming your needs map well to flow-oriented navigation and that you need some conversational state maintained.

                  Converting from MVC to SWF should only be trivially different for portlets than servlets. Your view definitions will still be HTML fragments instead of full pages, but otherwise normal SWF will work. There is a Portlet sample available with the Web Flow distribution, so that should be a good starting point.

                  Comment

                  Working...
                  X