Wicket
  1. Wicket
  2. WICKET-5380

Wicket rebinds the SessionEntry session attribute and this causes problems in Glassfish

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 6.10.0, 6.11.0
    • Fix Version/s: 6.12.0, 7.0.0-M1
    • Component/s: wicket
    • Labels:
      None

      Description

      With WICKET-5164 Wicket made org.apache.wicket.page.PageStoreManager.SessionEntry a javax.servlet.http.HttpSessionBindingListener to be notified when this session attribute is removed to be able to clean the disk data store when the session is replaced.

      This causes problems on Glassfish server (ver. 3 and 4) because GF notifies the HttpSessionBindingListener no matter whether the new value is different from the old one.
      Jetty and Tomcat check the new against the old value by identity and there is no problem.

      See this mail discussion for more details:
      http://markmail.org/thread/uigzwllvib2iohvu

        Issue Links

          Activity

          Hide
          Martin Grigorov added a comment -

          From now on SessionEntry is set as an attribute in the http session only after creating it. It won't be re-set on every request as until now.

          Show
          Martin Grigorov added a comment - From now on SessionEntry is set as an attribute in the http session only after creating it. It won't be re-set on every request as until now.
          Hide
          Paul Bors added a comment -

          Proposed fix was also tested on GlassFish 3.1.2.2 which works just as well as GF 4.x

          Show
          Paul Bors added a comment - Proposed fix was also tested on GlassFish 3.1.2.2 which works just as well as GF 4.x
          Hide
          Paul Bors added a comment -

          Also affects version 6.10.0 as this was caused by WICKET-5164.

          Show
          Paul Bors added a comment - Also affects version 6.10.0 as this was caused by WICKET-5164 .
          Hide
          Christoph Läubrich added a comment -

          As mentioned in WICKET-5473 this is a bad idea since it prevents the underlying session completelty from detecting changes in the set object.
          So if session is persited and afterwards restored (e.g. server restart), an old state might be presented to the application.

          Show
          Christoph Läubrich added a comment - As mentioned in WICKET-5473 this is a bad idea since it prevents the underlying session completelty from detecting changes in the set object. So if session is persited and afterwards restored (e.g. server restart), an old state might be presented to the application.

            People

            • Assignee:
              Martin Grigorov
              Reporter:
              Martin Grigorov
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development