Spring Framework
  1. Spring Framework
  2. SPR-6126

Clarify the meaning of SessionStatus.setComplete() in a Portlet environment

    Details

    • Type: Improvement Improvement
    • Status: Investigating
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 3.0 M4
    • Fix Version/s: 4.x Backlog
    • Component/s: Web
    • Labels:
      None

      Description

      See Forum reference for more detail

      Failing Test case:
      User opens a form in a JSR 286 portlet
      User changes data in the form,
      User clicks cancel button
      Form closes
      Data is (correctly) not persisted to db
      User opens form again
      User sees that the changes they made and canceled are still there. Changes should have been discarded by SessionStatus.setComplete()

      Switching portlet.xml to JSR 168 standard fixes the problem

        Issue Links

          Activity

          Hide
          Juergen Hoeller added a comment -

          Actually, what is being stored in the session there is the implicit model Map, which happens to contain 'stale' session attributes as well. However, those stale attributes are not being stored in the session directly anymore - just kept around as part of that implicit model Map. Do you have a problem with that specific fact? Trying to understand what actually remains here... From our perspective, 3.0.3 and in particular 3.0.4 did fix the problem.

          Juergen

          Show
          Juergen Hoeller added a comment - Actually, what is being stored in the session there is the implicit model Map, which happens to contain 'stale' session attributes as well. However, those stale attributes are not being stored in the session directly anymore - just kept around as part of that implicit model Map. Do you have a problem with that specific fact? Trying to understand what actually remains here... From our perspective, 3.0.3 and in particular 3.0.4 did fix the problem. Juergen
          Hide
          Ashish Sarin added a comment -

          I tested a portlet on 3.0.4 and did see that calling setComplete method of SessionStatus from action method of a portlet doesn't cleanup the session. It only works when you're calling setComplete method from a render method. The problem is - when one should call the setComplete method ? If we should call setComplete method in the render method (and it'll work), then it will recreate model attributes(specified as part of @SessionAttributes) on each render method call, making it irrelevant to use @SessionAttributes annotation.

          Show
          Ashish Sarin added a comment - I tested a portlet on 3.0.4 and did see that calling setComplete method of SessionStatus from action method of a portlet doesn't cleanup the session. It only works when you're calling setComplete method from a render method. The problem is - when one should call the setComplete method ? If we should call setComplete method in the render method (and it'll work), then it will recreate model attributes(specified as part of @SessionAttributes) on each render method call, making it irrelevant to use @SessionAttributes annotation.
          Hide
          Ashish Sarin added a comment -

          Just to clarify, this problem is not related to WebSphere or JSR 168. I saw this problem testing portlet on GateIn and Liferay portal servers.

          Ashish

          Show
          Ashish Sarin added a comment - Just to clarify, this problem is not related to WebSphere or JSR 168. I saw this problem testing portlet on GateIn and Liferay portal servers. Ashish
          Hide
          Abdulrhman Nabih ALKoptan added a comment -

          Hi , Any Update reading this issue ?

          Show
          Abdulrhman Nabih ALKoptan added a comment - Hi , Any Update reading this issue ?
          Hide
          Juergen Hoeller added a comment -

          Not from our side, I'm afraid. We're willing to revisit this issue but have yet to receive a concrete proposal on how to go about it.

          Admittedly, there's no focus on the Portlet support within the current Spring team, so we have to rely on community contributions...

          Juergen

          Show
          Juergen Hoeller added a comment - Not from our side, I'm afraid. We're willing to revisit this issue but have yet to receive a concrete proposal on how to go about it. Admittedly, there's no focus on the Portlet support within the current Spring team, so we have to rely on community contributions... Juergen

            People

            • Assignee:
              Juergen Hoeller
              Reporter:
              Brad Thurber
              Last updater:
              Juergen Hoeller
            • Votes:
              6 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Days since last comment:
                1 week ago