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 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 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 wrote:
> >>>
> Hi Wayne,
>
> the Eclipse .project still has 9.1.1 on the classpath:
>
>
> 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() ca
