You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Thomas Heigl <th...@umschalt.com> on 2019/04/22 16:47:49 UTC
HttpSessionDataStore in Wicket 9
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
Re: HttpSessionDataStore in Wicket 9
Posted by Sven Meier <sv...@meiers.net>.
Good question.
I'll have to check this and the untouch-feature next weekend.
Many thanks
Sven
>
> On 23.04.2019 at 22:37, <Thomas Heigl> wrote:
>
>
> 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 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 understan
d 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 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, 201
9 at 10:57 PM Sven Meier 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-unsubscribe@wicket.apache.org >> For additional commands, e-mail: users-help@wicket.apache.org >> >>
>
Re: HttpSessionDataStore in Wicket 9
Posted by Thomas Heigl <th...@umschalt.com>.
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 <th...@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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
Re: HttpSessionDataStore in Wicket 9
Posted by Thomas Heigl <th...@umschalt.com>.
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 <sv...@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 <sv...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: HttpSessionDataStore in Wicket 9
Posted by Sven Meier <sv...@meiers.net>.
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 <sv...@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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: HttpSessionDataStore in Wicket 9
Posted by Thomas Heigl <th...@umschalt.com>.
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 <sv...@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
> >
>
Re: HttpSessionDataStore in Wicket 9
Posted by Sven Meier <sv...@meiers.net>.
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
>