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