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