Hi Wayne,
the Eclipse .project still has 9.1.1 on the classpath:
<classpathentry kind="var"
path="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1.jar"
sourcepath="M2_REPO/org/apache/wicket/wicket-core/9.9.1/wicket-core-9.9.1-sources.jar"/>
Without that, flushing of the Session works fine here with my fix on 9.x
BTW the workaround with HubInSessionCache subclassing InSessionPageStore
(to use a separate MetaDataKey) is no longer needed.
Regards
Sven
On 26.05.22 19:19, Wayne W wrote:
Hello Sven,
So this particular issue I've been investigating might be a lack of my
understanding of wicket as much as a session issue, but it seems odd
and I'm fairly sure it's not correct. It appears I need to call
getSession().dirty();
as well within the ajax request for wicket to flush the updated model into
the session (in the onDetach -> internalDetach -> setAttribute ) otherwise
the model update is simply ignored. If I don't call dirty() then the model
is never persisted to the httlpsession via setAttribute() and the change is
lost.
Is that right?
Interestingly if I remove this from the Application:
*final* ISerializer serializer = *new* JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(*false*);
setPageManagerProvider(*new* DefaultPageManagerProvider(*this*) {
*protected* IPageStore newCachingStore(IPageStore pageStore)
{
*return* *new* CachingPageStore(pageStore, *new* HubInSessionCache(
serializer));
}
});
Then I do not need to call dirty(). Is this because the httpsession is not
used I presume?
If I do not use persisted tomcat session in redis it's ok though when not
calling dirty() - this because as I explained before, setAttribute is not
being called on the tomcat httpsession on the next request to the AjaxLink.
The redis tomcat is looking for calls to the setAttribute to store the
updated session into redis , and without that explicit dirty() call it
doesn't happen.
Here is a quickstart if you want:
https://customerservices.glasscubes.com/share/s/mvecp90dlvqlp3p2b744q0gps4
You will need a bog standard redis instance running on your machine though
to test. Check the path is correct in Start.java line 84.
Line 74 in HomePage.java has the dirty commented out at the moment.
Enter some text into the textfield and you will see the model is updated
(printed out). However when you click on the AjaxLink 'next' the model is
null.
Let me know your thoughts
Many thanks.
On Wed, May 25, 2022 at 4:19 PM Wayne W <waynemailingli...@gmail.com> wrote:
Hi Sven,
Many thanks.
I've built 9,x and the changes seem to be there, but I still have the
issue. I will try and create a quickstart reproducing this issue and get
back to you.
Wayne
On Wed, May 25, 2022 at 8:34 AM Sven Meier <s...@meiers.net> wrote:
Hi Wayne,
I've pushed a fix to
https://github.com/apache/wicket/tree/WICKET-6981-session-attributes-not-set
Are you able to test this on your setup?
Regards
Sven
On 24.05.22 10:43, Wayne W wrote:
Hello Sven,
Any update on this?
Many thanks
On Mon, May 16, 2022 at 11:40 AM Sven Meier <s...@meiers.net> wrote:
Hi Wayne,
not, because InSessionPageStore#canBeAsynchronous returns false,
thereby
preventing asynchronous adds.
Regards
Sven
On 16.05.22 09:37, Wayne W wrote:
Ah that's great Sven.
Just a question - is it necessary for me to call
getStoreSettings().setAsynchronous(false); when wanting to support
http
session setup?
I saw a post about this quite some time ago but I'm not sure.
Thanks for clarifying
On Sun, May 15, 2022 at 8:54 PM Sven Meier <s...@meiers.net> wrote:
Hi Wayne,
I've create an issue for this bug:
https://issues.apache.org/jira/browse/WICKET-6981
I think I have a fix ready, but have to give it some more tests.
Thanks for reporting the issue.
Sven
On 10.05.22 23:25, Sven Meier wrote:
Hi Wayne,
Is this a bug?
could be, do we have a Jira issue already?
I think there might be a call to Session#setMetaData() missing.
Before
Wicket 9.x it seemed to have been called additionally when a page is
stored in the session.
I'll take a deeper look into this tomorrow.
Best regards
Sven
On 10.05.22 18:47, Wayne W wrote:
Hi,
I am *still* trying to troubleshoot why migrating to 9.4 we have
found that
our app no longer supports session failover correctly. We use
Redission to
store the tomcat session in Redis.
After a lot of debugging it appears that for
AjaxFormComponentUpdatingBehavior.onEvent() calls,
HttpSessionStore.flushSession() is never called after. And changes
to
the
model are not persisted in the HTTP Session and into Redis backed
store.
The reason is setAttribute is never called on the session and
therefore the
updated session with good model values is never persisted. And when
the
next call arrives, the page is pulled back out of Redis/Http
session
without the changes.
I had to do the following to get the wicket session to be stored in
the
session within our Application:
ISerializer serializer = new JavaSerializer(getApplicationKey());
getFrameworkSettings().setSerializer(serializer);
getStoreSettings().setAsynchronous(false);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
protected IPageStore newCachingStore(IPageStore
pageStore)
{
return new CachingPageStore(pageStore, new
InSessionPageStore( 2,
serializer));
}
});
The objects are updated in the session page object instance
correctly
with
AjaxFormComponentUpdatingBehavior , however this issue is they are
never
saved/persisted as setAttribute is not called. So the next request
comes
and a new page object instance is unserialized from the store
without
the
changes.
Is this a bug?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
