Or was the original version of `GaePageManagerProvider` with 2 sessions
stores actually correct with the first one acting as a non-serialized cache?
Best,
Thomas
On Tue, Apr 23, 2019 at 9:57 PM Thomas Heigl <tho...@umschalt.com> wrote:
> 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
>>
>>
