Hi Sven,
This works, but now we do not have any in-memory caching layer anymore and
the page has to be deserialized on *every* ajax request.
The API does not "feel" just right as well. It is very hard to understand
what's going on and why we are overriding the `newSessionStore` method,
without looking at the whole implementation of `DefaultPageManagerProvider`.
What I'd really like to do is approximate the pre-Wicket 9 behavior of my
provider implementation:
setPageManagerProvider(new DefaultPageManagerProvider(this) {
> @Override
> protected IDataStore newDataStore() {
> return new HttpSessionDataStore(getPageManagerContext(), new
> PageNumberEvictionStrategy(10));
> }
> });
If I understand the previous implementation correctly, the store chain in
Wicket 8 with my configuration would have looked something like this:
RequestStore -> *SessionCache* (in PageStoreManager) -> InSessionStore
After every request, touched pages are stored in the session cache and do
not have to be deserialized on the next request to the same page.
This setup works very well for us and since we have an application with a
ton of concurrent users, I want to keep the configuration as close to the
Wicket 8 implementation as possible when upgrading to Wicket 9.
I guess we can get close to the Wicket 8 setup by using the following
chain, but I'm not sure if it will behave the same and have the same memory
requirements:
RequestStore -> *InMemoryStore* (size per session = 1) -> InSessionStore
Do you have any other ideas on this?
If we find the right configuration, you could also add other default
implementations of `IPageManagerProvider` that make it easier for users
with custom setups to migrate to the new version without the strange noop
method overrides.
Best,
Thomas
On Tue, Apr 23, 2019 at 8:39 PM Sven Meier <s...@meiers.net> wrote:
> Hi Thomas,
>
> you're right, I've changed it to single InSessionStore.
>
> Have fun
> Sven
>
> Am 23.04.19 um 09:06 schrieb Thomas Heigl:
> > Hi Sven,
> >
> > Thanks a lot for the quick reply!
> >
> > Are you sure the code in GaePageManagerProvider is correct? Don't we end
> up
> > with two instances of InSessionPageStore in this case? Once as
> > `newSessionStore` and once as `newPersistentStore`?
> >
> > The resulting chain looks like this: RequestSore -> *InSessionStore* ->
> > AsynchronousStore -> SerializingStore -> CryptingStore ->
> *InSessionStore*
> >
> > Best,
> >
> > Thomas
> >
> >
> > On Mon, Apr 22, 2019 at 10:57 PM Sven Meier <s...@meiers.net> wrote:
> >
> >> Hi Thomas,
> >>
> >> many thanks for testing so early!
> >>
> >> Set a custom provider of the page manager, see wicketstuff's
> >> gae-initializer as an example:
> >>
> >> application.setPageManagerProvider(new
> >> GaePageManagerProvider(application, maxPages));
> >>
> >>
> >>
> https://github.com/wicketstuff/core/blob/master/gae-initializer-parent/gae-initializer/src/main/java/org/wicketstuff/gae/GaePageManagerProvider.java
> >>
> >> Have fun
> >> Sven
> >>
> >>
> >> Am 22.04.19 um 18:47 schrieb Thomas Heigl:
> >>> Hi all,
> >>>
> >>> I just experimentally upgraded my application to 9.0.0-M1. Most things
> >> are
> >>> straight forward, but I'm struggling with replicating my current page
> >>> manager configuration using the new API.
> >>>
> >>> My current configuration for Wicket 8 looks like this:
> >>>
> >>> setPageManagerProvider(new DefaultPageManagerProvider(this) {
> >>>> @Override
> >>>> protected IDataStore newDataStore() {
> >>>> return new HttpSessionDataStore(getPageManagerContext(), new
> >>>> PageNumberEvictionStrategy(10));
> >>>> }
> >>>> });
> >>> What is the Wicket 9 equivalent of this?
> >>>
> >>> Thanks,
> >>>
> >>> Thomas
> >>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
