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
>
>
