Hi Sven,
So far so good. It seems to have fixed all issues.
Will there be a release for this anytime soon do you think?
Thanks
On Wed, Jun 22, 2022 at 8:45 PM Sven Meier <s...@meiers.net> wrote:
> Hi Wayne,
>
> I pushed a fix to Wicket 9.x and 10.x.
>
> Would be great if you could give this a test, your test application
> works fine now.
>
> Many thanks
> Sven
>
>
> On 20.06.22 18:19, Wayne W wrote:
> > Hello Sven,
> >
> > Many thanks for looking into this. It's greatly appreciated that you
> > understand what is happening here.
> >
> > Out of interest I just had a look at the RedissionSession setAttribute
> and
> > it's just calling
> org.apache.catalina.session.StandardSession.setAttribute(
> > name, value, notify) and all the unBound calls are done in there. So
> > perhaps this is an issue with different versions of Tomcat?
> >
> > FYI RedissionSession:
> >
> > *public* *void* setAttribute(String name, Object value, *boolean*
> notify)
> > {
> >
> > *super*.setAttribute(name, value, notify);
> >
> >
> >
> > *if* (value == *null*) {
> >
> > *return*;
> >
> > }
> >
> > *if* (updateMode == UpdateMode.*DEFAULT* && map != *null*) {
> >
> > fastPut(name, value);
> >
> > }
> >
> > *if* (readMode == ReadMode.*REDIS*) {
> >
> > loadedAttributes.put(name, value);
> >
> > updatedAttributes.put(name, value);
> >
> > }
> >
> > *if* (updateMode == UpdateMode.*AFTER_REQUEST*) {
> >
> > removedAttributes.remove(name);
> >
> > }
> >
> > }
> >
> > Either way looking forward to the fix.
> >
> > On Sun, Jun 19, 2022 at 10:09 PM Sven Meier <s...@meiers.net> wrote:
> >
> >> Hi again,
> >>
> >> I found the cause of this bug:
> >>
> >> RedissonSession exposes a behavior we've seen before, which seems not to
> >> be a problem with the default Tomcat session implementation:
> >> When an attribute is set on the session, the previously set attribute is
> >> removed first - this leads to #valueUnbound() being called, signalling
> >> PersistentPageStore to drop all store pages.
> >>
> >> I'll perpare a fix tomorrow.
> >>
> >> Thanks for your report.
> >> Sven
> >>
> >>
> >> On 18.06.22 15:24, Sven Meier wrote:
> >>> Hi,
> >>>
> >>> I've stripped all pageManager related settings from your application.
> >>>
> >>> Now the bug only appears with Tomcat's RedissonSessionManager, without
> >>> it the detailPages open as expected.
> >>>
> >>> I'm no expert in Redis, so I don't know what is going wrong there. Can
> >>> you confirm my observation so far?
> >>>
> >>> Regards
> >>> Sven
> >>>
> >>>
> >>> On 13.06.22 12:30, Wayne W wrote:
> >>>> Hi Sven,
> >>>>
> >>>> Ok here is a quickstart demonstrating the issue.
> >>>>
> >>
> https://customerservices.glasscubes.com/share/s/1usch8t0hpjc4s5l3219he7s8f
> >>>>
> >>>> To reproduce, open localhost:8080 and you will now also see a list of
> 4
> >>>> links. If you right click each link and open in a new window, you
> >>>> will see
> >>>> that only the first tab will render correctly. The other tabs just
> >>>> refresh
> >>>> the page.
> >>>>
> >>>> If you change the wicket version to say 9.4.0 and do the same you
> >>>> will see
> >>>> that each page opens correctly in a new tab, and clicking on the link
> in
> >>>> the page outputs "this" to the console correctly.
> >>>>
> >>>> Let me know your thoughts
> >>>> I will of course try and understand whats happening.
> >>>>
> >>>>
> >>>> On Thu, Jun 9, 2022 at 8:45 AM Sven Meier <s...@meiers.net> wrote:
> >>>>
> >>>>> Hi Wayne,
> >>>>>
> >>>>> no idea on my side.
> >>>>>
> >>>>> Please compare without InSessionPageStore and with different max
> pages.
> >>>>>
> >>>>> If the problem persists, please provide a quickstart.
> >>>>>
> >>>>> Thanks
> >>>>> Sven
> >>>>>
> >>>>>
> >>>>> On 08.06.22 18:51, Wayne W wrote:
> >>>>>> Hi Sven,
> >>>>>>
> >>>>>> I'm having a new issue with this wicket version - I've yet had time
> to
> >>>>> dig
> >>>>>> deep and try and make a quickstart to replicate it. However I
> >>>>>> thought I
> >>>>>> would describe it first to see if it rings any bells in your head!
> >>>>>>
> >>>>>> In our app we have a file explorer like page that lists a bunch of
> >>>>>> files.
> >>>>>> Clicking one of these opens a popup over the page to see the
> >>>>>> details. We
> >>>>>> used to be able to open each of these files in a new browser tab.
> >>>>> However,
> >>>>>> now when the new tabs are opened, the details load ok, but when the
> >>>>>> user
> >>>>>> clicks on the wicket link to close the popup we are getting
> >>>>>> componentsnotfound in the page.
> >>>>>>
> >>>>>> Something about opening new browser tabs is messing up the session
> and
> >>>>>> loosing the components. I presume this is something to do with
> >>>>>> InSessionPageStore. Opening a single new tab is fine, it when there
> >>>>>> are
> >>>>>> more than 2 in total. I tried increasing the maxPages to 20 for
> >>>>>> InSessionPageStore
> >>>>>> but it made no difference.
> >>>>>>
> >>>>>> Any idea?
> >>>>>>
> >>>>>> On Wed, Jun 8, 2022 at 10:43 AM Sven Meier <s...@meiers.net> wrote:
> >>>>>>
> >>>>>>> Thanks Wayne!
> >>>>>>>
> >>>>>>> The fix will be part of the next 9.x release.
> >>>>>>>
> >>>>>>> Best regards
> >>>>>>> Sven
> >>>>>>>
> >>>>>>>
> >>>>>>> On 07.06.22 12:22, Wayne W wrote:
> >>>>>>>> Hi Sven,
> >>>>>>>>
> >>>>>>>> I can confirm your fix is working .
> >>>>>>>>
> >>>>>>>> I suppose it will be a while before this reaches an official
> >>>>>>>> release?
> >>>>>>>> Thanks for your help - really appreciated.
> >>>>>>>>
> >>>>>>>> Wayne
> >>>>>>>>
> >>>>>>>> On Sun, May 29, 2022 at 10:47 PM Sven Meier <s...@meiers.net>
> >> wrote:
> >>>>>>>>> Hi Wayne,
> >>>>>>>>>
> >>>>>>>>> the Eclipse .project still has 9.1.1 on the classpath:
> >>>>>>>>>
> >>>>>>>>> <classpathentry kind="var"
> >>>>>>>>>
> >> path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"
> >>>>>
> >>
> sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>
> >>
> >>>>>>>>> Without that, flushing of the Session works fine here with my
> >>>>>>>>> fix on
> >>>>> 9.x
> >>>>>>>>> BTW the workaround with HubInSessionCache subclassing
> >>>>> InSessionPageStore
> >>>>>>>>> (to use a separate MetaDataKey) is no longer needed.
> >>>>>>>>>
> >>>>>>>>> Regards
> >>>>>>>>> Sven
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On 26.05.22 19:19, Wayne W wrote:
> >>>>>>>>>> Hello Sven,
> >>>>>>>>>>
> >>>>>>>>>> So this particular issue I've been investigating might be a
> >>>>>>>>>> lack of
> >>>>> my
> >>>>>>>>>> understanding of wicket as much as a session issue, but it
> >>>>>>>>>> seems odd
> >>>>>>>>>> and I'm fairly sure it's not correct. It appears I need to call
> >>>>>>>>>> getSession().dirty();
> >>>>>>>>>> as well within the ajax request for wicket to flush the updated
> >>>>>>>>>> model
> >>>>>>>>> into
> >>>>>>>>>> the session (in the onDetach -> internalDetach -> setAttribute )
> >>>>>>>>> otherwise
> >>>>>>>>>> the model update is simply ignored. If I don't call dirty()
> >>>>>>>>>> then the
> >>>>>>>>> model
> >>>>>>>>>> is never persisted to the httlpsession via setAttribute() and
> the
> >>>>>>> change
> >>>>>>>>> is
> >>>>>>>>>> lost.
> >>>>>>>>>>
> >>>>>>>>>> Is that right?
> >>>>>>>>>>
> >>>>>>>>>> Interestingly if I remove this from the Application:
> >>>>>>>>>>
> >>>>>>>>>> *final* ISerializer serializer = *new*
> >>>>>>>>> JavaSerializer(getApplicationKey());
> >>>>>>>>>> getFrameworkSettings().setSerializer(serializer);
> >>>>>>>>>>
> >>>>>>>>>> getStoreSettings().setAsynchronous(*false*);
> >>>>>>>>>>
> >>>>>>>>>> setPageManagerProvider(*new* DefaultPageManagerProvider(*this*)
> {
> >>>>>>>>>>
> >>>>>>>>>> *protected* IPageStore
> newCachingStore(IPageStore
> >>>>>>> pageStore)
> >>>>>>>>>> {
> >>>>>>>>>>
> >>>>>>>>>> *return* *new* CachingPageStore(pageStore, *new*
> >>>>>>>>> HubInSessionCache(
> >>>>>>>>>> serializer));
> >>>>>>>>>>
> >>>>>>>>>> }
> >>>>>>>>>>
> >>>>>>>>>> });
> >>>>>>>>>>
> >>>>>>>>>> Then I do not need to call dirty(). Is this because the
> >>>>>>>>>> httpsession
> >>>>> is
> >>>>>>>>> not
> >>>>>>>>>> used I presume?
> >>>>>>>>>>
> >>>>>>>>>> If I do not use persisted tomcat session in redis it's ok
> >>>>>>>>>> though when
> >>>>>>> not
> >>>>>>>>>> calling dirty() - this because as I explained before,
> >>>>>>>>>> setAttribute is
> >>>>>>> not
> >>>>>>>>>> being called on the tomcat httpsession on the next request to
> the
> >>>>>>>>> AjaxLink.
> >>>>>>>>>> The redis tomcat is looking for calls to the setAttribute to
> store
> >>>>> the
> >>>>>>>>>> updated session into redis , and without that explicit dirty()
> >>>>>>>>>> call
> >>>>> it
> >>>>>>>>>> doesn't happen.
> >>>>>>>>>>
> >>>>>>>>>> Here is a quickstart if you want:
> >>>>>>>>>>
> >>
> https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4
> >>>>>>>>>> You will need a bog standard redis instance running on your
> >>>>>>>>>> machine
> >>>>>>>>> though
> >>>>>>>>>> to test. Check the path is correct in Start.java line 84.
> >>>>>>>>>> Line 74 in HomePage.java has the dirty commented out at the
> >>>>>>>>>> moment.
> >>>>>>>>>>
> >>>>>>>>>> Enter some text into the textfield and you will see the model is
> >>>>>>> updated
> >>>>>>>>>> (printed out). However when you click on the AjaxLink 'next' the
> >>>>> model
> >>>>>>> is
> >>>>>>>>>> null.
> >>>>>>>>>>
> >>>>>>>>>> Let me know your thoughts
> >>>>>>>>>> Many thanks.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> On Wed, May 25, 2022 at 4:19 PM Wayne W
> >>>>>>>>>> <waynemailingli...@gmail.com
> >>>>>>>>> wrote:
> >>>>>>>>>>> Hi Sven,
> >>>>>>>>>>>
> >>>>>>>>>>> Many thanks.
> >>>>>>>>>>>
> >>>>>>>>>>> I've built 9,x and the changes seem to be there, but I still
> have
> >>>>> the
> >>>>>>>>>>> issue. I will try and create a quickstart reproducing this
> >>>>>>>>>>> issue and
> >>>>>>> get
> >>>>>>>>>>> back to you.
> >>>>>>>>>>>
> >>>>>>>>>>> Wayne
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, May 25, 2022 at 8:34 AM Sven Meier <s...@meiers.net>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hi Wayne,
> >>>>>>>>>>>>
> >>>>>>>>>>>> I've pushed a fix to
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>
> https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set
> >>>>>>>>>>>> Are you able to test this on your setup?
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regards
> >>>>>>>>>>>> Sven
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> On 24.05.22 10:43, Wayne W wrote:
> >>>>>>>>>>>>> Hello Sven,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Any update on this?
> >>>>>>>>>>>>> Many thanks
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, May 16, 2022 at 11:40 AM Sven Meier <s...@meiers.net
> >
> >>>>>>> wrote:
> >>>>>>>>>>>>>> Hi Wayne,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> not, because InSessionPageStore#canBeAsynchronous returns
> >>>>>>>>>>>>>> false,
> >>>>>>>>>>>> thereby
> >>>>>>>>>>>>>> preventing asynchronous adds.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regards
> >>>>>>>>>>>>>> Sven
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 16.05.22 09:37, Wayne W wrote:
> >>>>>>>>>>>>>>> Ah that's great Sven.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Just a question - is it necessary for me to call
> >>>>>>>>>>>>>>> getStoreSettings().setAsynchronous(false); when wanting to
> >>>>> support
> >>>>>>>>>>>> http
> >>>>>>>>>>>>>>> session setup?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I saw a post about this quite some time ago but I'm not
> sure.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Thanks for clarifying
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Sun, May 15, 2022 at 8:54 PM Sven Meier <
> s...@meiers.net>
> >>>>>>> wrote:
> >>>>>>>>>>>>>>>> Hi Wayne,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I've create an issue for this bug:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/WICKET-6981
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> I think I have a fix ready, but have to give it some more
> >>>>> tests.
> >>>>>>>>>>>>>>>> Thanks for reporting the issue.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Sven
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 10.05.22 23:25, Sven Meier wrote:
> >>>>>>>>>>>>>>>>> Hi Wayne,
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Is this a bug?
> >>>>>>>>>>>>>>>>> could be, do we have a Jira issue already?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think there might be a call to Session#setMetaData()
> >>>>> missing.
> >>>>>>>>>>>> Before
> >>>>>>>>>>>>>>>>> Wicket 9.x it seemed to have been called additionally
> >>>>>>>>>>>>>>>>> when a
> >>>>>>> page
> >>>>>>>>> is
> >>>>>>>>>>>>>>>>> stored in the session.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I'll take a deeper look into this tomorrow.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Best regards
> >>>>>>>>>>>>>>>>> Sven
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 10.05.22 18:47, Wayne W wrote:
> >>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I am *still* trying to troubleshoot why migrating to
> >>>>>>>>>>>>>>>>>> 9.4 we
> >>>>>>> have
> >>>>>>>>>>>>>>>>>> found that
> >>>>>>>>>>>>>>>>>> our app no longer supports session failover correctly.
> >>>>>>>>>>>>>>>>>> We use
> >>>>>>>>>>>>>>>>>> Redission to
> >>>>>>>>>>>>>>>>>> store the tomcat session in Redis.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> After a lot of debugging it appears that for
> >>>>>>>>>>>>>>>>>> AjaxFormComponentUpdatingBehavior.onEvent() calls,
> >>>>>>>>>>>>>>>>>> HttpSessionStore.flushSession() is never called after.
> And
> >>>>>>>>> changes
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> model are not persisted in the HTTP Session and into
> Redis
> >>>>>>> backed
> >>>>>>>>>>>>>> store.
> >>>>>>>>>>>>>>>>>> The reason is setAttribute is never called on the
> >>>>>>>>>>>>>>>>>> session and
> >>>>>>>>>>>>>>>>>> therefore the
> >>>>>>>>>>>>>>>>>> updated session with good model values is never
> persisted.
> >>>>> And
> >>>>>>>>> when
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> next call arrives, the page is pulled back out of
> >>>>>>>>>>>>>>>>>> Redis/Http
> >>>>>>>>>>>> session
> >>>>>>>>>>>>>>>>>> without the changes.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I had to do the following to get the wicket session to
> be
> >>>>>>> stored
> >>>>>>>>> in
> >>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> session within our Application:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> ISerializer serializer = new
> >>>>>>> JavaSerializer(getApplicationKey());
> >>>>>>>>>>>>>>>>>> getFrameworkSettings().setSerializer(serializer);
> >>>>>>>>>>>>>>>>>> getStoreSettings().setAsynchronous(false);
> >>>>>>>>>>>>>>>>>> setPageManagerProvider(new
> >>>>>>>>>>>>>>>>>> DefaultPageManagerProvider(this) {
> >>>>>>>>>>>>>>>>>> protected IPageStore
> >>>>>>> newCachingStore(IPageStore
> >>>>>>>>>>>>>> pageStore)
> >>>>>>>>>>>>>>>>>> {
> >>>>>>>>>>>>>>>>>> return new CachingPageStore(pageStore,
> new
> >>>>>>>>>>>>>>>>>> InSessionPageStore( 2,
> >>>>>>>>>>>>>>>>>> serializer));
> >>>>>>>>>>>>>>>>>> }
> >>>>>>>>>>>>>>>>>> });
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> The objects are updated in the session page object
> >>>>>>>>>>>>>>>>>> instance
> >>>>>>>>>>>> correctly
> >>>>>>>>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>> AjaxFormComponentUpdatingBehavior , however this issue
> is
> >>>>> they
> >>>>>>>>> are
> >>>>>>>>>>>>>> never
> >>>>>>>>>>>>>>>>>> saved/persisted as setAttribute is not called. So the
> next
> >>>>>>>>> request
> >>>>>>>>>>>>>> comes
> >>>>>>>>>>>>>>>>>> and a new page object instance is unserialized from the
> >>>>>>>>>>>>>>>>>> store
> >>>>>>>>>>>> without
> >>>>>>>>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Is this a bug?
> >>>>>>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> users-unsubscr...@wicket.apache.org
> >>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>>> users-h...@wicket.apache.org
> >>>>>>>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> users-unsubscr...@wicket.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>> users-h...@wicket.apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> users-h...@wicket.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>>>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
