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