Hi,
>'org.apache.wicket.pageStore.InSessionPageStore' can not be asynchronous
yes, pages cannot be stored in the session asynchronously. Same holds
for the old HttpSessionDataStore in Wicket 8.x.
>Adding this fixes the warning getStoreSettings().setAsynchronous(false);
Yes, that's the correct fix.
>Might this clustered use-case be common enough to justify adding another
>IPageManagerProvider implementation to Wicket with default behavior more
>appropriate for clustering?
As you've seen, there are many possible combinations for these page stores:
https://github.com/apache/wicket/blob/master/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L43
I'm not sure which concrete combination would be *the* most appropriate
for clustering.
Have fun
Sven
On 20.01.21 18:34, Greb Lindqvist wrote:
Overriding #newPersistentStore() should be enough:
Thank you for your response.
I tried only overriding newPersistentStore() like this
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
});
but get warnings like
WARN o.a.w.p.AsynchronousPageStore - Delegated page store
'org.apache.wicket.pageStore.InSessionPageStore' can not be asynchronous
Adding this fixes the warning
getStoreSettings().setAsynchronous(false);
but looking at the DefaultPageManagerProvider chain:
RequestPageStore -> CachingPageStore -> SerializingPageStore
-> AsynchronousPageStore -> CryptingPageStore -> DiskPageStore
CachingPageStore wraps an InSessionPageStore of its own but I'm thinking
that is not useful when clustering - especially since I'm
using DeflatedJavaSerializer and want it invoked before storing in the
session. For clustering, maybe this makes more sense (assuming using
something like Spring Session)
RequestPageStore -> SerializingPageStore -> CryptingPageStore
-> InSessionPageStore
It seems like this does what I want but I need to test more.
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
@Override
protected IPageStore newCachingStore(IPageStore pageStore) {
return pageStore;
}
@Override
protected IPageStore newAsynchronousStore(IPageStore pageStore)
{
return pageStore;
}
});
Might this clustered use-case be common enough to justify adding another
IPageManagerProvider implementation to Wicket with default behavior more
appropriate for clustering?
Thanks again
On Tue, Jan 19, 2021 at 11:57 AM Sven Meier <s...@meiers.net> wrote:
Hi,
> Is it helpful if I add documentation issues to Wicket Jira?
pull-requests are always preferred :P
>
https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
I will take care of this.
>For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is
that
> a good replacement for my Wicket 8 code?
Overriding #newPersistentStore() should be enough:
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
>Wicket alive and well! I've been using it since 1.3 :)
Thanks for reporting back.
Regards
Sven
On 19.01.21 16:02, Greb Lindqvist wrote:
Hello everyone,
I'm updating an application from Wicket 8 to Wicket 9 and see that
IDataStore has been removed. I think the documentation needs to be
updated
here
https://ci.apache.org/projects/wicket/guide/9.x/single.html#_httpsessiondatastore
Is it helpful if I add documentation issues to Wicket Jira?
My application uses
https://spring.io/projects/spring-session-data-redis
so it can be clustered.
My Wicket 8 code is like
setSessionStoreProvider(HttpSessionStore::new);
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
protected IDataStore newDataStore() {
return new HttpSessionDataStore(getPageManagerContext(),
new PageNumberEvictionStrategy(20));
}
});
For Wicket 9 I'm overriding DefaultPageManagerProvider like below. Is
that
a good replacement for my Wicket 8 code? It seems to mostly work but I'm
seeing slight weirdness that doesn't happen in Wicket 8. If
overriding DefaultPageManagerProvider is the correct approach, it would
be
helpful to mention it in the migration guide with a pointer to the
updated
documentation.
Thanks to everyone for keeping Wicket alive and well! I've been using it
since 1.3 :)
setPageManagerProvider(new DefaultPageManagerProvider(this) {
@Override
public IPageManager get()
{
IPageStore store = newPersistentStore();
store = newSerializingStore(store);
store = newRequestStore(store);
return new PageManager(store);
}
@Override
protected IPageStore newPersistentStore() {
return new InSessionPageStore(20);
}
});
---------------------------------------------------------------------
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
