You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Wayne W <wa...@gmail.com> on 2022/05/10 16:47:21 UTC
FlushSession never called on AjaxFormComponentUpdatingBehavior
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?
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
Ah thank you. Wasn't aware of that.
On Mon, May 16, 2022 at 11:40 AM Sven Meier <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
Great thanks!
On Tue, Jun 28, 2022 at 9:18 PM Sven Meier <sv...@meiers.net> wrote:
> +1
>
> Sven
>
> On 28.06.22 18:54, Andrea Del Bene wrote:
> > I think we have enough work done for 9.11.0, so you shouldn't have to
> wait
> > too much to get it
> >
> > On Tue, Jun 28, 2022 at 5:00 PM Wayne W <wa...@gmail.com>
> wrote:
> >
> >> 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 <sv...@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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
> >>>>>>>>>>>>> <waynemailinglists@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 <sven@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 <
> >> sven@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 <
> >>> sven@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >>> users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> >> users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
+1
Sven
On 28.06.22 18:54, Andrea Del Bene wrote:
> I think we have enough work done for 9.11.0, so you shouldn't have to wait
> too much to get it
>
> On Tue, Jun 28, 2022 at 5:00 PM Wayne W <wa...@gmail.com> wrote:
>
>> 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 <sv...@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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
>>>>>>>>>>>>> <waynemailinglists@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 <sv...@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 <
>> sven@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 <
>>> sven@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>>> users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>>> To unsubscribe, e-mail:
>> users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Andrea Del Bene <an...@gmail.com>.
I think we have enough work done for 9.11.0, so you shouldn't have to wait
too much to get it
On Tue, Jun 28, 2022 at 5:00 PM Wayne W <wa...@gmail.com> wrote:
> 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 <sv...@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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
> > >>>>>>>>>> <waynemailinglists@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 <sv...@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 <
> sven@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 <
> > sven@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-unsubscribe@wicket.apache.org
> > >>>>>>>>>>>>>>>>> For additional commands, e-mail:
> > >>>>>>>>>>>>>>>>> users-help@wicket.apache.org
> > >>>>>>>>>>>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> > users-unsubscribe@wicket.apache.org
> > >>>>>>>>>>>>>>>> For additional commands, e-mail:
> > >>>>>>>>>>>>>>>> users-help@wicket.apache.org
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>
> > ---------------------------------------------------------------------
> > >>>>>>>>>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
> > >>>>>>>>>>>>>> For additional commands, e-mail:
> > users-help@wicket.apache.org
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>>>>>>>>>> For additional commands, e-mail:
> users-help@wicket.apache.org
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >> ---------------------------------------------------------------------
> > >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>
> > ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>>>
> > >>>>>>>
> > >>>>>
> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>>>
> > >>>>>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >> For additional commands, e-mail: users-help@wicket.apache.org
> > >>
> > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
--
Andrea Del Bene.
Apache Wicket committer.
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
> >>>>>>>>>> <waynemailinglists@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 <sv...@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 <sven@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 <
> sven@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>>>>>>>>> To unsubscribe, e-mail:
> users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> users-help@wicket.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
>>>>>>>>>> <waynemailinglists@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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 <sv...@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 <sv...@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
> >>>>>>>> <waynemailinglists@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>>>> For additional commands, e-mail:
> >>>>>>>>>>>>>> users-help@wicket.apache.org
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>> ---------------------------------------------------------------------
> >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>>
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <sv...@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 <sv...@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
>>>>>>>> <waynemailinglists@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail:
>>>>>>>>>>>>>> users-help@wicket.apache.org
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>> ---------------------------------------------------------------------
>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <sv...@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 <sv...@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 <waynemailinglists@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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 <sv...@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 <waynemailinglists@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>>
> >>>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <sv...@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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>>
>>>> ---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>>
>>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>>
> >> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>>
>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>>
>>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>>
> >>>>>>>
> ---------------------------------------------------------------------
> >>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>>>
> >>>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>>
>>>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <wa...@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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>>
>> >>>> ---------------------------------------------------------------------
>> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >>>> For additional commands, e-mail: users-help@wicket.apache.org
>> >>>>
>> >>>>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> >> For additional commands, e-mail: users-help@wicket.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>>
> >>>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
Hello Sven,
Any update on this?
Many thanks
On Mon, May 16, 2022 at 11:40 AM Sven Meier <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Wayne W <wa...@gmail.com>.
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 <sv...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: FlushSession never called on AjaxFormComponentUpdatingBehavior
Posted by Sven Meier <sv...@meiers.net>.
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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org