Announcement Announcement Module
Collapse
No announcement yet.
Spring Portlet MVC and session creation Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring Portlet MVC and session creation

    Hi!

    I have written a small sample portlet using the Spring Portlet MVC framework. There was one thing that caused pain: there was always a portlet session created - but I had to avoid session creation (special requirement).

    I tracked down the problem to the following lines in method handleActionRequestInternal in file AbstractFormController (line 403):

    Code:
    		// Get the session and prepare the command object.
    		PortletSession session = request.getPortletSession();
    		Object command = null;
    
    		// Check for invalid submit in session mode.
    		boolean validSubmit = (!isSessionForm() ||
    				(session != null && session.getAttribute(getFormSessionAttributeName()) != null));
    getPortletSession() "Returns the current portlet session or, if there is no current session, creates one and returns the new session." (comment from JavaDoc)

    Together with the check "session != null", I think that the call to getPortletSession() should pass false as parameter, which indicates that no new session should be created.

    Please, can someone check if this is a bug?

    (Source is cut'n'paste from build 416.)

    Thank you!

    Kai

  • #2
    I am sorry for not responding to this sooner. I am very delinquent in reviewing forum posts.

    You raise an excellent point. I will make the appropriate change, test it, and commit it assuming everything still works properly.

    Comment


    • #3
      I've updated the code you mentioned so that it will no longer create a session when it does not already exist. This was actually a good update because I was able to sync this up with the servlet-side code more so after some refactoring that we had done earlier.

      However, your original reason for looking at this will still be a problem. Any controller based on BaseCommandController (which includes AbstractCommandController, AbstractFormController, SimpleFormController, and AbstractWizardFormController) will create a session.

      The reason for this is that we need to create the command object and the errors object during the action phase and then make those objects available to the render phase for display. The only way to do this is via the session. This happens regardless of whether it is considered a "sessionForm" or not.

      This is caused by an unfortunate limitation in the JSR-168 spec -- there is no mechanism for passing objects from the action phase to the render phase other than the sesssion.

      At this point, if you have a hard requirement for a controller that does not result in a user session, you must use AbstractController directly and then look at how to do the rest of what you need in your form from there.

      Comment


      • #4
        Can you use setRenderParameter ?

        The setRenderParameter methods allow for direct communication of data from the action processing phase to the render phase.

        Comment


        • #5
          Unfortunately, we cannot use setRenderParameter to pass forward from the action phase the data we need in the render phase.

          The data we need to pass forward is the 'command' object and the 'errors' object. The command object is an arbitrary POJO that is being bound to the form. The errors object contains all the results of binding and validating that command object.

          The render parameters are only string value name pairs, and so to use them for these objects, the objects would have to be serialized. We actually experimented with that at one point, but then ran into a brick wall: some portals will put all the render parameters into the URL that is sent to the browser in order to provide back button support. In that case, our serialized objects quickly caused the URL to exceed the 4k length limitation from the specs (and the 2k length limitation of some browsers). So this left us with only the session as a viable way to send this data forward.

          Comment

          Working...
          X