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