Re: Page locked for a long time

2020-07-06 Thread Thomas Heigl
We've been using Martin's solution with JQueryFileUpload for years and it
works great.

Best,

Thomas

On Mon, Jul 6, 2020 at 8:59 AM Maxim Solodovnik 
wrote:

> Thanks a million :))
>
> On Mon, 6 Jul 2020 at 13:43, Martin Grigorov  wrote:
>
> > On Sun, Jul 5, 2020 at 9:16 PM Sven Meier  wrote:
> >
> > > Hi Maxim,
> > >
> > > you'll have to upload these files to a resource separately.
> > >
> > > I'm not aware of a reusable solution for that.
> > >
> >
> > Here is a blog article on this topic:
> > http://wicketinaction.com/2012/11/uploading-files-to-wicket-iresource/
> and
> > its demo app: https://github.com/martin-g/blogs/tree/master/file-upload
> >
> >
> > >
> > > Have fun
> > > Sven
> > >
> > >
> > > On 05.07.20 17:20, Maxim Solodovnik wrote:
> > > > Hello All,
> > > >
> > > > our app allows huge file uploads
> > > > I have noticed the page is locked while incoming input stream is
> being
> > > > copied
> > > > (might take more than an hour)
> > > >
> > > >   at java.base@11.0.7/java.io.InputStream.read(InputStream.java:205)
> > > > at org.apache.commons.fileupload.util.Streams.copy(Streams.java:98)
> > > > at org.apache.commons.fileupload.util.Streams.copy(Streams.java:68)
> > > > at
> > > >
> > >
> >
> org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:346)
> > > > at
> > > >
> > >
> >
> org.apache.wicket.protocol.http.servlet.MultipartServletWebRequestImpl.parseFileParts(MultipartServletWebRequestImpl.java:196)
> > > > at
> > > org.apache.wicket.markup.html.form.Form.handleMultiPart(Form.java:1470)
> > > >
> > > > Are there any options to prevent page lock?
> > > >
> > >
> > > -
> > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > > For additional commands, e-mail: users-h...@wicket.apache.org
> > >
> > >
> >
>
>
> --
> Best regards,
> Maxim
>


Feedback on Jira Issues

2020-05-05 Thread Thomas Heigl
Hi all,

I created two more tickets for potential improvements that showed up during
profiling:

- https://issues.apache.org/jira/projects/WICKET/issues/WICKET-6776
- https://issues.apache.org/jira/projects/WICKET/issues/WICKET-6780

Both are not urgent, because I was able to override the problematic
behavior in my application, but it would be great if someone could give me
some feedback so I can go ahead and create PRs if my suggestions make sense.

Thanks and best regards,

Thomas


Re: SessionStore on database

2020-04-29 Thread Thomas Heigl
Hi,

There are two options I'm aware of:

- You can use a session manager in your application server that stores your
session in the database. I.e. Tomcat's JDBC store.
- You can use Spring Session with a JDBC store

I recently implemented Spring Session for Wicket with Redis as a backing
store. There are minor issues with page locking that require some custom
code, but otherwise it works fine.

Best regards,

Thomas

On Wed, Apr 29, 2020 at 5:30 AM ShengChe Hsiao  wrote:

> Dear all
>
> I want to implement cross datacenter session replication for my web app,
> can I persist session on shared database? If it does, how can I do?
>
> I searched the web, and found org.apache.wicket.protocol.http.
> SecondLevelCacheSessionStore.IClusteredPageStore
>
> I have an idea for implement above interface and persist session on target
> database, right?
>
> 
> --->
> To boldly go where no man has gone before.
> 
> --->
> We do this not because it is easy. We do this because it is hard.
> -
> -->
> If I have seen further it is by standing on the shoulders of giants.
> --
> ->
> front...@gmail.com
>
> ->
>


Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-16 Thread Thomas Heigl
Hi Martin,

If the next release is not too far away, I'd rather wait.

I'm already pushing a milestone to production and don't want to copy large
chunks of code to my project as well ;)

Best regards,

Thomas

On Thu, Apr 16, 2020 at 1:33 PM Martin Grigorov 
wrote:

> Hi Thomas,
>
> On Thu, Apr 16, 2020 at 1:41 PM Thomas Heigl  wrote:
>
> > Thanks Sven!
> >
> > I think the solution is good enough for now.
> >
> > Would it be possible to do a 9.0.0-M5.1 release for this? If so, I would
> > give it another try on production.
> >
>
> It would be easier to copy the class temporarily in your project and fix
> the import in YourApplication.java.
> You can revert this change with the next release.
>
>
> >
> > Best regards,
> >
> > Thomas
> >
> > On Wed, Apr 15, 2020 at 11:57 PM Sven Meier  wrote:
> >
> > > Hi Thomas,
> > >
> > > I've pushed a change for
> > > https://issues.apache.org/jira/browse/WICKET-6769 to master.
> > >
> > > I'm not sure about the API right now, but it allows you to easily use
> > > any other map implementation.
> > >
> > > Caffeine's Cache#asMap() should work fine with here, although I didn't
> > > test it myself.
> > >
> > > Have fun
> > > Sven
> > >
> > >
> > > On 12.04.20 20:41, Thomas Heigl wrote:
> > > > Hi Sven,
> > > >
> > > > I was thinking about this as well.
> > > >
> > > > SoftReferences worked well in my application. G1GC seems to start to
> > > evict
> > > > them when -XX:InitiatingHeapOccupancyPercent is reached. In my case,
> > when
> > > > the heap is around 60% full.
> > > > But as you said, there is no real control over which references are
> > > evicted
> > > > and it is much harder to monitor the current state of the memory map.
> > > >
> > > > We are already using Caffeine extensively and your suggested solution
> > > would
> > > > allow me much more control over the cache.
> > > > We could still use SoftReferences with Caffeine if we wanted to in
> > > addition
> > > > to setting a global limit on cache size and an eviction policy.
> > > >
> > > > To avoid calling an overridable method from the constructor you could
> > > add a
> > > > Supplier> argument. I usually choose a
> > > > supplier-based approach in such cases.
> > > >
> > > > Let's go for this solution!
> > > >
> > > > Best regards,
> > > >
> > > > Thomas
> > > >
> > > >
> > > >
> > > > On Sun, Apr 12, 2020 at 6:57 PM Sven Meier  wrote:
> > > >
> > > >> Hi Thomas,
> > > >>
> > > >> I've did a little research on using SoftReferences for caches:
> > > >>
> > > >>
> > >
> >
> https://stackoverflow.com/questions/264582/is-there-a-softhashmap-in-java
> > > >>
> > > >>
> > >
> >
> http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html
> > > >>
> > > >> The experts seem to agree that depending on the GC to clean up your
> > > >> cache is a bad idea:
> > > >>
> > > >> - you can't control which elements in the cache are evicted first
> > > >> - eviction happens only when the system is low on memory
> > > >>
> > > >> Best option would be using Guava's CacheBuilder:
> > > >>
> > > >> https://github.com/google/guava/wiki/CachesExplained
> > > >>
> > > >> IMHO these are very special solutions and we don't actually need to
> > > >> integrate one of them into Wicket.
> > > >> Instead we can leave that decision to your application, by adding an
> > > >> overridable method to InMemoryPageStore:
> > > >>
> > > >>   /**
> > > >>* Create a map to hold memory data for all sessions.
> > > >>*
> > > >>* @return a {@link ConcurrentHashMap} by default
> > > >>*/
> > > >>   protected Map newMemoryMap()
> > > >>   {
> > > >>   return new ConcurrentHashMap<>();
> > > >>   }
> > > >>
> > > >> (Yes, it would be called from the constructor which is a bad
>

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-16 Thread Thomas Heigl
Thanks Sven!

I think the solution is good enough for now.

Would it be possible to do a 9.0.0-M5.1 release for this? If so, I would
give it another try on production.

Best regards,

Thomas

On Wed, Apr 15, 2020 at 11:57 PM Sven Meier  wrote:

> Hi Thomas,
>
> I've pushed a change for
> https://issues.apache.org/jira/browse/WICKET-6769 to master.
>
> I'm not sure about the API right now, but it allows you to easily use
> any other map implementation.
>
> Caffeine's Cache#asMap() should work fine with here, although I didn't
> test it myself.
>
> Have fun
> Sven
>
>
> On 12.04.20 20:41, Thomas Heigl wrote:
> > Hi Sven,
> >
> > I was thinking about this as well.
> >
> > SoftReferences worked well in my application. G1GC seems to start to
> evict
> > them when -XX:InitiatingHeapOccupancyPercent is reached. In my case, when
> > the heap is around 60% full.
> > But as you said, there is no real control over which references are
> evicted
> > and it is much harder to monitor the current state of the memory map.
> >
> > We are already using Caffeine extensively and your suggested solution
> would
> > allow me much more control over the cache.
> > We could still use SoftReferences with Caffeine if we wanted to in
> addition
> > to setting a global limit on cache size and an eviction policy.
> >
> > To avoid calling an overridable method from the constructor you could
> add a
> > Supplier> argument. I usually choose a
> > supplier-based approach in such cases.
> >
> > Let's go for this solution!
> >
> > Best regards,
> >
> > Thomas
> >
> >
> >
> > On Sun, Apr 12, 2020 at 6:57 PM Sven Meier  wrote:
> >
> >> Hi Thomas,
> >>
> >> I've did a little research on using SoftReferences for caches:
> >>
> >>
> https://stackoverflow.com/questions/264582/is-there-a-softhashmap-in-java
> >>
> >>
> http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html
> >>
> >> The experts seem to agree that depending on the GC to clean up your
> >> cache is a bad idea:
> >>
> >> - you can't control which elements in the cache are evicted first
> >> - eviction happens only when the system is low on memory
> >>
> >> Best option would be using Guava's CacheBuilder:
> >>
> >> https://github.com/google/guava/wiki/CachesExplained
> >>
> >> IMHO these are very special solutions and we don't actually need to
> >> integrate one of them into Wicket.
> >> Instead we can leave that decision to your application, by adding an
> >> overridable method to InMemoryPageStore:
> >>
> >>   /**
> >>    * Create a map to hold memory data for all sessions.
> >>*
> >>* @return a {@link ConcurrentHashMap} by default
> >>*/
> >>   protected Map newMemoryMap()
> >>   {
> >>   return new ConcurrentHashMap<>();
> >>   }
> >>
> >> (Yes, it would be called from the constructor which is a bad practice by
> >> itself, but this is the simplest solution.)
> >>
> >> What do you think?
> >>
> >> Sven
> >>
> >>
> >> On 12.04.20 10:34, Thomas Heigl wrote:
> >>> Hi Sven,
> >>>
> >>> That's good to hear! Please let me know when you have an implementation
> >> and
> >>> I'll give it another go.
> >>>
> >>> Best regards,
> >>>
> >>> Thomas
> >>>
> >>> On Sat, Apr 11, 2020 at 11:01 PM Sven Meier  wrote:
> >>>
> >>>> Hi Thomas,
> >>>>
> >>>> actually not bad news at all (for Wicket 9 at least).
> >>>>
> >>>> The old page manager implementation had so many special concepts and
> >>>> solutions, it's easy to miss one.
> >>>>
> >>>> A soft reference feature can easily be added/restored. I'm already
> >>>> checking where it fits best.
> >>>>
> >>>> Thanks for your thorough testing.
> >>>>
> >>>> Best regards
> >>>> Sven
> >>>>
> >>>>
> >>>> On 11.04.20 10:58, Thomas Heigl wrote:
> >>>>> Hi all,
> >>>>>
> >>>>> Bad news. My application was caught in a GC loop after running for 8
> >>>> hours.
> >>>>> The old generation

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-12 Thread Thomas Heigl
Hi Sven,

I was thinking about this as well.

SoftReferences worked well in my application. G1GC seems to start to evict
them when -XX:InitiatingHeapOccupancyPercent is reached. In my case, when
the heap is around 60% full.
But as you said, there is no real control over which references are evicted
and it is much harder to monitor the current state of the memory map.

We are already using Caffeine extensively and your suggested solution would
allow me much more control over the cache.
We could still use SoftReferences with Caffeine if we wanted to in addition
to setting a global limit on cache size and an eviction policy.

To avoid calling an overridable method from the constructor you could add a
Supplier> argument. I usually choose a
supplier-based approach in such cases.

Let's go for this solution!

Best regards,

Thomas



On Sun, Apr 12, 2020 at 6:57 PM Sven Meier  wrote:

> Hi Thomas,
>
> I've did a little research on using SoftReferences for caches:
>
> https://stackoverflow.com/questions/264582/is-there-a-softhashmap-in-java
>
> http://jeremymanson.blogspot.com/2009/07/how-hotspot-decides-to-clear_07.html
>
> The experts seem to agree that depending on the GC to clean up your
> cache is a bad idea:
>
> - you can't control which elements in the cache are evicted first
> - eviction happens only when the system is low on memory
>
> Best option would be using Guava's CacheBuilder:
>
>https://github.com/google/guava/wiki/CachesExplained
>
> IMHO these are very special solutions and we don't actually need to
> integrate one of them into Wicket.
> Instead we can leave that decision to your application, by adding an
> overridable method to InMemoryPageStore:
>
>  /**
>   * Create a map to hold memory data for all sessions.
>   *
>   * @return a {@link ConcurrentHashMap} by default
>   */
>  protected Map newMemoryMap()
>  {
>  return new ConcurrentHashMap<>();
>  }
>
> (Yes, it would be called from the constructor which is a bad practice by
> itself, but this is the simplest solution.)
>
> What do you think?
>
> Sven
>
>
> On 12.04.20 10:34, Thomas Heigl wrote:
> > Hi Sven,
> >
> > That's good to hear! Please let me know when you have an implementation
> and
> > I'll give it another go.
> >
> > Best regards,
> >
> > Thomas
> >
> > On Sat, Apr 11, 2020 at 11:01 PM Sven Meier  wrote:
> >
> >> Hi Thomas,
> >>
> >> actually not bad news at all (for Wicket 9 at least).
> >>
> >> The old page manager implementation had so many special concepts and
> >> solutions, it's easy to miss one.
> >>
> >> A soft reference feature can easily be added/restored. I'm already
> >> checking where it fits best.
> >>
> >> Thanks for your thorough testing.
> >>
> >> Best regards
> >> Sven
> >>
> >>
> >> On 11.04.20 10:58, Thomas Heigl wrote:
> >>> Hi all,
> >>>
> >>> Bad news. My application was caught in a GC loop after running for 8
> >> hours.
> >>> The old generation was exhausted.
> >>>
> >>> I couldn't get a heap dump at that time but restarted the application,
> >> took
> >>> a heap dump after about an hour, and reverted back to Wicket 8.
> >>>
> >>> The problem is this: The heap was full of objects referencing
> >>> InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My
> first
> >>> thought was that there is something wrong with the implementation of
> that
> >>> store and pages do not get limited or removed correctly.  So I debugged
> >>> it locally but everything is working fine.
> >>>
> >>> Then I noticed that there are a lot of instances of Hibernate entities
> on
> >>> the heap. So there definitely is an issue with models somewhere in my
> >>> application. To be sure that this is not a new issue, I took another
> heap
> >>> dump from production - now running Wicket 8 again - and compared it.
> >>> There are undetached entity models on the heap as well.
> >>>
> >>> So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
> >>> (roughly the equivalent of InMemoryPageStore in Wicket 9) uses
> >>> SoftReferences for storing pages. InMemoryPageStore does not and GC
> >> cannot
> >>> reclaim memory from it.
> >>>
> >>> So while this surfaced some issues in my application that I just
> fixed, I
> >>> believe that InMemoryPageStore should use Sof

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-12 Thread Thomas Heigl
Hi Sven,

That's good to hear! Please let me know when you have an implementation and
I'll give it another go.

Best regards,

Thomas

On Sat, Apr 11, 2020 at 11:01 PM Sven Meier  wrote:

> Hi Thomas,
>
> actually not bad news at all (for Wicket 9 at least).
>
> The old page manager implementation had so many special concepts and
> solutions, it's easy to miss one.
>
> A soft reference feature can easily be added/restored. I'm already
> checking where it fits best.
>
> Thanks for your thorough testing.
>
> Best regards
> Sven
>
>
> On 11.04.20 10:58, Thomas Heigl wrote:
> > Hi all,
> >
> > Bad news. My application was caught in a GC loop after running for 8
> hours.
> > The old generation was exhausted.
> >
> > I couldn't get a heap dump at that time but restarted the application,
> took
> > a heap dump after about an hour, and reverted back to Wicket 8.
> >
> > The problem is this: The heap was full of objects referencing
> > InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My first
> > thought was that there is something wrong with the implementation of that
> > store and pages do not get limited or removed correctly.  So I debugged
> > it locally but everything is working fine.
> >
> > Then I noticed that there are a lot of instances of Hibernate entities on
> > the heap. So there definitely is an issue with models somewhere in my
> > application. To be sure that this is not a new issue, I took another heap
> > dump from production - now running Wicket 8 again - and compared it.
> > There are undetached entity models on the heap as well.
> >
> > So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
> > (roughly the equivalent of InMemoryPageStore in Wicket 9) uses
> > SoftReferences for storing pages. InMemoryPageStore does not and GC
> cannot
> > reclaim memory from it.
> >
> > So while this surfaced some issues in my application that I just fixed, I
> > believe that InMemoryPageStore should use SoftReferences or another
> > implementation based on SoftReferences should be added to Wicket 9. A
> cache
> > should not consume all the memory if it can easily re-fetch
> > the value from persistent storage.
> >
> > I guess the reason for not using SoftReferences in InMemoryPageStore is
> > that it can theoretically be used as a "persistent" store for pages. If
> that
> > behavior is really required, I suggest adding another implementation
> using
> > SoftReferences.
> >
> > Best regards,
> >
> > Thomas
> >
> > On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov 
> > wrote:
> >
> >> On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl 
> wrote:
> >>
> >>> FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k
> requests
> >>> served and no issues so far.
> >>>
> >> Awesome!
> >> Thank you for testing it!
> >>
> >>
> >>> Great work!
> >>>
> >>> Thomas
> >>>
> >>> On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:
> >>>
> >>>> Many thanks Maxim!
> >>>>
> >>>> Sven
> >>>>
> >>>> On 08.04.20 14:29, Maxim Solodovnik wrote:
> >>>>> Released :)
> >>>>>
> >>>>> On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 
> >>>> wrote:
> >>>>>> OK
> >>>>>>
> >>>>>> Will start new release process in couple of hours
> >>>>>> Please stop me if you will find any blocker :)
> >>>>>>
> >>>>>> On Wed, 8 Apr 2020 at 14:36, Thomas Heigl 
> >>> wrote:
> >>>>>>> Hi Maxim,
> >>>>>>>
> >>>>>>> It works for me now!
> >>>>>>>
> >>>>>>> Thomas
> >>>>>>>
> >>>>>>> On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik <
> >>> solomax...@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Thanks a million!
> >>>>>>>>
> >>>>>>>> On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 
> >>>> wrote:
> >>>>>>>>> Hi Maxim,
> >>>>>>>>>
> >>>>>>>>> I'm testing against the snapshot now. Will get back to you
> >> shortly.
> >>>>>>>>

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-11 Thread Thomas Heigl
Hi all,

Bad news. My application was caught in a GC loop after running for 8 hours.
The old generation was exhausted.

I couldn't get a heap dump at that time but restarted the application, took
a heap dump after about an hour, and reverted back to Wicket 8.

The problem is this: The heap was full of objects referencing
InMemoryPageStore, i.e. the in-memory 2nd-level cache for pages. My first
thought was that there is something wrong with the implementation of that
store and pages do not get limited or removed correctly.  So I debugged
it locally but everything is working fine.

Then I noticed that there are a lot of instances of Hibernate entities on
the heap. So there definitely is an issue with models somewhere in my
application. To be sure that this is not a new issue, I took another heap
dump from production - now running Wicket 8 again - and compared it.
There are undetached entity models on the heap as well.

So why does it not OOM with Wicket 8? Well, the PerSessionPageStore
(roughly the equivalent of InMemoryPageStore in Wicket 9) uses
SoftReferences for storing pages. InMemoryPageStore does not and GC cannot
reclaim memory from it.

So while this surfaced some issues in my application that I just fixed, I
believe that InMemoryPageStore should use SoftReferences or another
implementation based on SoftReferences should be added to Wicket 9. A cache
should not consume all the memory if it can easily re-fetch
the value from persistent storage.

I guess the reason for not using SoftReferences in InMemoryPageStore is
that it can theoretically be used as a "persistent" store for pages. If that
behavior is really required, I suggest adding another implementation using
SoftReferences.

Best regards,

Thomas

On Fri, Apr 10, 2020 at 7:19 PM Martin Grigorov 
wrote:

> On Fri, Apr 10, 2020 at 4:01 PM Thomas Heigl  wrote:
>
> > FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k requests
> > served and no issues so far.
> >
>
> Awesome!
> Thank you for testing it!
>
>
> >
> > Great work!
> >
> > Thomas
> >
> > On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:
> >
> > > Many thanks Maxim!
> > >
> > > Sven
> > >
> > > On 08.04.20 14:29, Maxim Solodovnik wrote:
> > > > Released :)
> > > >
> > > > On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 
> > > wrote:
> > > >> OK
> > > >>
> > > >> Will start new release process in couple of hours
> > > >> Please stop me if you will find any blocker :)
> > > >>
> > > >> On Wed, 8 Apr 2020 at 14:36, Thomas Heigl 
> > wrote:
> > > >>> Hi Maxim,
> > > >>>
> > > >>> It works for me now!
> > > >>>
> > > >>> Thomas
> > > >>>
> > > >>> On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik <
> > solomax...@gmail.com>
> > > >>> wrote:
> > > >>>
> > > >>>> Thanks a million!
> > > >>>>
> > > >>>> On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 
> > > wrote:
> > > >>>>> Hi Maxim,
> > > >>>>>
> > > >>>>> I'm testing against the snapshot now. Will get back to you
> shortly.
> > > >>>>>
> > > >>>>> Thomas
> > > >>>>>
> > > >>>>> On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik <
> > > solomax...@gmail.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> Hello All,
> > > >>>>>>
> > > >>>>>> M5 seems to be broken (deploy has failed more than 10 times
> during
> > > my
> > > >>>>>> build attempts)
> > > >>>>>> I have to start another release
> > > >>>>>> Could you please tell when can I start?
> > > >>>>>>
> > > >>>>>> On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik <
> > solomax...@gmail.com
> > > >
> > > >>>>>> wrote:
> > > >>>>>>> Hello Thomas,
> > > >>>>>>>
> > > >>>>>>> Please test M6-SNAPSHOT (so I don't have to release M5.2 :
> > > >>>>>>>
> > > >>>>>>> On Wed, 8 Apr 2020 at 02:39, Thomas Heigl  >
> > > >>>> wrote:
> > > >>>>>>>> Hi Maxim,
> > > >>>&g

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-10 Thread Thomas Heigl
FYI: I deployed Wicket 9.0.0-M5 to production an hour ago. 100k requests
served and no issues so far.

Great work!

Thomas

On Wed, Apr 8, 2020 at 3:13 PM Sven Meier  wrote:

> Many thanks Maxim!
>
> Sven
>
> On 08.04.20 14:29, Maxim Solodovnik wrote:
> > Released :)
> >
> > On Wed, 8 Apr 2020 at 15:41, Maxim Solodovnik 
> wrote:
> >> OK
> >>
> >> Will start new release process in couple of hours
> >> Please stop me if you will find any blocker :)
> >>
> >> On Wed, 8 Apr 2020 at 14:36, Thomas Heigl  wrote:
> >>> Hi Maxim,
> >>>
> >>> It works for me now!
> >>>
> >>> Thomas
> >>>
> >>> On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik 
> >>> wrote:
> >>>
> >>>> Thanks a million!
> >>>>
> >>>> On Wed, 8 Apr 2020 at 14:10, Thomas Heigl 
> wrote:
> >>>>> Hi Maxim,
> >>>>>
> >>>>> I'm testing against the snapshot now. Will get back to you shortly.
> >>>>>
> >>>>> Thomas
> >>>>>
> >>>>> On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik <
> solomax...@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Hello All,
> >>>>>>
> >>>>>> M5 seems to be broken (deploy has failed more than 10 times during
> my
> >>>>>> build attempts)
> >>>>>> I have to start another release
> >>>>>> Could you please tell when can I start?
> >>>>>>
> >>>>>> On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik  >
> >>>>>> wrote:
> >>>>>>> Hello Thomas,
> >>>>>>>
> >>>>>>> Please test M6-SNAPSHOT (so I don't have to release M5.2 :
> >>>>>>>
> >>>>>>> On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 
> >>>> wrote:
> >>>>>>>> Hi Maxim,
> >>>>>>>>
> >>>>>>>> That would be great. I want to do some more extensive testing and
> >>>> then
> >>>>>>>> deploy M5 into production. ;)
> >>>>>>>>
> >>>>>>>> Thomas
> >>>>>>>>
> >>>>>>>> On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik <
> >>>> solomax...@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> I can pack another release
> >>>>>>>>> later this week ...
> >>>>>>>>>
> >>>>>>>>> On Wed, 8 Apr 2020 at 00:48, Thomas Heigl 
> >>>>>> wrote:
> >>>>>>>>>> Thanks Sven!
> >>>>>>>>>>
> >>>>>>>>>> Did your changes make it into the release? Or did they just
> >>>> miss
> >>>>>> it?
> >>>>>>>>>> Thomas
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Apr 7, 2020 at 7:43 PM Sven Meier 
> >>>> wrote:
> >>>>>>>>>>> Hi Thomas,
> >>>>>>>>>>>
> >>>>>>>>>>> yes, you're right:
> >>>>>>>>>>>
> >>>>>>>>>>> wicketstuff data stores missed some adjustments to the latest
> >>>>>> updates
> >>>>>>>>> in
> >>>>>>>>>>> wicket-core.
> >>>>>>>>>>>
> >>>>>>>>>>> And SessionQuotaManagingDataStore$DelegatedPage must be
> >>>>>> serializable of
> >>>>>>>>>>> course.
> >>>>>>>>>>>
> >>>>>>>>>>> I've pushed changes to wicketstuff master.
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks
> >>>>>>>>>>> Sven
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On 07.04.20 14:14, Thomas Heigl wrote:
> >>>>>>>>>>>> And one more thing. There is now a warning logged just
>

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-08 Thread Thomas Heigl
Hi Maxim,

It works for me now!

Thomas

On Wed, Apr 8, 2020 at 9:17 AM Maxim Solodovnik 
wrote:

> Thanks a million!
>
> On Wed, 8 Apr 2020 at 14:10, Thomas Heigl  wrote:
> >
> > Hi Maxim,
> >
> > I'm testing against the snapshot now. Will get back to you shortly.
> >
> > Thomas
> >
> > On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik 
> > wrote:
> >
> > > Hello All,
> > >
> > > M5 seems to be broken (deploy has failed more than 10 times during my
> > > build attempts)
> > > I have to start another release
> > > Could you please tell when can I start?
> > >
> > > On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik 
> > > wrote:
> > > >
> > > > Hello Thomas,
> > > >
> > > > Please test M6-SNAPSHOT (so I don't have to release M5.2 :
> > > >
> > > > On Wed, 8 Apr 2020 at 02:39, Thomas Heigl 
> wrote:
> > > > >
> > > > > Hi Maxim,
> > > > >
> > > > > That would be great. I want to do some more extensive testing and
> then
> > > > > deploy M5 into production. ;)
> > > > >
> > > > > Thomas
> > > > >
> > > > > On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik <
> solomax...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > I can pack another release
> > > > > > later this week ...
> > > > > >
> > > > > > On Wed, 8 Apr 2020 at 00:48, Thomas Heigl 
> > > wrote:
> > > > > > >
> > > > > > > Thanks Sven!
> > > > > > >
> > > > > > > Did your changes make it into the release? Or did they just
> miss
> > > it?
> > > > > > >
> > > > > > > Thomas
> > > > > > >
> > > > > > > On Tue, Apr 7, 2020 at 7:43 PM Sven Meier 
> wrote:
> > > > > > >
> > > > > > > > Hi Thomas,
> > > > > > > >
> > > > > > > > yes, you're right:
> > > > > > > >
> > > > > > > > wicketstuff data stores missed some adjustments to the latest
> > > updates
> > > > > > in
> > > > > > > > wicket-core.
> > > > > > > >
> > > > > > > > And SessionQuotaManagingDataStore$DelegatedPage must be
> > > serializable of
> > > > > > > > course.
> > > > > > > >
> > > > > > > > I've pushed changes to wicketstuff master.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Sven
> > > > > > > >
> > > > > > > >
> > > > > > > > On 07.04.20 14:14, Thomas Heigl wrote:
> > > > > > > > > And one more thing. There is now a warning logged just
> before
> > > > > > > > serialization:
> > > > > > > > >
> > > > > > > > > WARN o.a.w.pageStore.AsynchronousPageStore: Delegated
> page
> > > store
> > > > > > > > >> 'org.apache.wicket.pageStore.SerializingPageStore' can
> not be
> > > > > > > > asynchronous
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl <
> > > tho...@umschalt.com>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > >> The cause is the following MetaData entry in the session:
> > > > > > > > >>
> > > > > > > > >> class
> > > > > > > > >>>
> > > > > > > >
> > > > > >
> > >
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
> > > > > > > > >>
> > > > > > > > >> On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl <
> > > tho...@umschalt.com>
> > > > > > > > wrote:
> > > > > > > > >>
> > > > > >

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-08 Thread Thomas Heigl
Hi Maxim,

I'm testing against the snapshot now. Will get back to you shortly.

Thomas

On Wed, Apr 8, 2020 at 2:53 AM Maxim Solodovnik 
wrote:

> Hello All,
>
> M5 seems to be broken (deploy has failed more than 10 times during my
> build attempts)
> I have to start another release
> Could you please tell when can I start?
>
> On Wed, 8 Apr 2020 at 07:01, Maxim Solodovnik 
> wrote:
> >
> > Hello Thomas,
> >
> > Please test M6-SNAPSHOT (so I don't have to release M5.2 :))))
> >
> > On Wed, 8 Apr 2020 at 02:39, Thomas Heigl  wrote:
> > >
> > > Hi Maxim,
> > >
> > > That would be great. I want to do some more extensive testing and then
> > > deploy M5 into production. ;)
> > >
> > > Thomas
> > >
> > > On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik 
> > > wrote:
> > >
> > > > I can pack another release
> > > > later this week ...
> > > >
> > > > On Wed, 8 Apr 2020 at 00:48, Thomas Heigl 
> wrote:
> > > > >
> > > > > Thanks Sven!
> > > > >
> > > > > Did your changes make it into the release? Or did they just miss
> it?
> > > > >
> > > > > Thomas
> > > > >
> > > > > On Tue, Apr 7, 2020 at 7:43 PM Sven Meier  wrote:
> > > > >
> > > > > > Hi Thomas,
> > > > > >
> > > > > > yes, you're right:
> > > > > >
> > > > > > wicketstuff data stores missed some adjustments to the latest
> updates
> > > > in
> > > > > > wicket-core.
> > > > > >
> > > > > > And SessionQuotaManagingDataStore$DelegatedPage must be
> serializable of
> > > > > > course.
> > > > > >
> > > > > > I've pushed changes to wicketstuff master.
> > > > > >
> > > > > > Thanks
> > > > > > Sven
> > > > > >
> > > > > >
> > > > > > On 07.04.20 14:14, Thomas Heigl wrote:
> > > > > > > And one more thing. There is now a warning logged just before
> > > > > > serialization:
> > > > > > >
> > > > > > > WARN o.a.w.pageStore.AsynchronousPageStore: Delegated page
> store
> > > > > > >> 'org.apache.wicket.pageStore.SerializingPageStore' can not be
> > > > > > asynchronous
> > > > > > >
> > > > > > >
> > > > > > > On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl <
> tho...@umschalt.com>
> > > > wrote:
> > > > > > >
> > > > > > >> The cause is the following MetaData entry in the session:
> > > > > > >>
> > > > > > >> class
> > > > > > >>>
> > > > > >
> > > >
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
> > > > > > >>
> > > > > > >> On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl <
> tho...@umschalt.com>
> > > > > > wrote:
> > > > > > >>
> > > > > > >>> Hi Sven,
> > > > > > >>>
> > > > > > >>> I just found time to give this a try with Wicket 9.0.0-M5.
> There
> > > > seem
> > > > > > to
> > > > > > >>> be issues with serialization now.
> > > > > > >>>
> > > > > > >>> My new config:
> > > > > > >>>
> > > > > > >>> protected IPageStore newCachingStore(IPageStore pageStore) {
> > > > > > >>>> return new CachingPageStore(pageStore, new
> > > > > > InMemoryPageStore(getName(),
> > > > > > >>>> MAX_PAGES_CACHED_PER_SESSION));
> > > > > > >>>> }
> > > > > > >>>> protected IPageStore newPersistentStore() {
> > > > > > >>>> final RedissonRedisCache redisCache = new
> > > > > > >>>> RedissonRedisCache(redissonClient);
> > > > > > >>>> final RedisDataStore redisDataStore = new
> > > > RedisDataStore(getName(),
> > > > > > >>>> redi

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Thomas Heigl
Hi Maxim,

That would be great. I want to do some more extensive testing and then
deploy M5 into production. ;)

Thomas

On Tue, Apr 7, 2020 at 7:50 PM Maxim Solodovnik 
wrote:

> I can pack another release
> later this week ...
>
> On Wed, 8 Apr 2020 at 00:48, Thomas Heigl  wrote:
> >
> > Thanks Sven!
> >
> > Did your changes make it into the release? Or did they just miss it?
> >
> > Thomas
> >
> > On Tue, Apr 7, 2020 at 7:43 PM Sven Meier  wrote:
> >
> > > Hi Thomas,
> > >
> > > yes, you're right:
> > >
> > > wicketstuff data stores missed some adjustments to the latest updates
> in
> > > wicket-core.
> > >
> > > And SessionQuotaManagingDataStore$DelegatedPage must be serializable of
> > > course.
> > >
> > > I've pushed changes to wicketstuff master.
> > >
> > > Thanks
> > > Sven
> > >
> > >
> > > On 07.04.20 14:14, Thomas Heigl wrote:
> > > > And one more thing. There is now a warning logged just before
> > > serialization:
> > > >
> > > > WARN o.a.w.pageStore.AsynchronousPageStore: Delegated page store
> > > >> 'org.apache.wicket.pageStore.SerializingPageStore' can not be
> > > asynchronous
> > > >
> > > >
> > > > On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl 
> wrote:
> > > >
> > > >> The cause is the following MetaData entry in the session:
> > > >>
> > > >> class
> > > >>>
> > >
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
> > > >>
> > > >> On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl 
> > > wrote:
> > > >>
> > > >>> Hi Sven,
> > > >>>
> > > >>> I just found time to give this a try with Wicket 9.0.0-M5. There
> seem
> > > to
> > > >>> be issues with serialization now.
> > > >>>
> > > >>> My new config:
> > > >>>
> > > >>> protected IPageStore newCachingStore(IPageStore pageStore) {
> > > >>>> return new CachingPageStore(pageStore, new
> > > InMemoryPageStore(getName(),
> > > >>>> MAX_PAGES_CACHED_PER_SESSION));
> > > >>>> }
> > > >>>> protected IPageStore newPersistentStore() {
> > > >>>> final RedissonRedisCache redisCache = new
> > > >>>> RedissonRedisCache(redissonClient);
> > > >>>> final RedisDataStore redisDataStore = new
> RedisDataStore(getName(),
> > > >>>> redisCache, new RedisSettings());
> > > >>>> return new SessionQuotaManagingDataStore(redisDataStore,
> > > >>>> DATA_STORE_MAX_BYTES_PER_SESSION);
> > > >>>> }
> > > >>>
> > > >>> This exception is logged after requests:
> > > >>>
> > > >>> org.springframework.data.redis.serializer.SerializationException:
> > > Cannot
> > > >>>> serialize; nested exception is
> > > >>>>
> > >
> org.springframework.core.serializer.support.SerializationFailedException:
> > > >>>> Failed to serialize object using DefaultSerializer; nested
> exception
> > > is
> > > >>>> java.io.NotSerializableException:
> > > >>>>
> > >
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
> > > >>>> at
> > > >>>>
> > >
> org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:96)
> > > >>>> at
> > > >>>>
> > >
> org.springframework.data.redis.core.AbstractOperations.rawHashValue(AbstractOperations.java:185)
> > > >>>> at
> > > >>>>
> > >
> org.springframework.data.redis.core.DefaultHashOperations.putAll(DefaultHashOperations.java:147)
> > > >>>> at
> > > >>>>
> > >
> org.springframework.data.redis.core.DefaultBoundHashOperations.putAll(DefaultBoundHashOperations.java:147)
> > > >>>> at
> > > >>>>
> > >
> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.saveDelta(RedisIndexedSessionRepository.java:79

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Thomas Heigl
Thanks Sven!

Did your changes make it into the release? Or did they just miss it?

Thomas

On Tue, Apr 7, 2020 at 7:43 PM Sven Meier  wrote:

> Hi Thomas,
>
> yes, you're right:
>
> wicketstuff data stores missed some adjustments to the latest updates in
> wicket-core.
>
> And SessionQuotaManagingDataStore$DelegatedPage must be serializable of
> course.
>
> I've pushed changes to wicketstuff master.
>
> Thanks
> Sven
>
>
> On 07.04.20 14:14, Thomas Heigl wrote:
> > And one more thing. There is now a warning logged just before
> serialization:
> >
> > WARN o.a.w.pageStore.AsynchronousPageStore: Delegated page store
> >> 'org.apache.wicket.pageStore.SerializingPageStore' can not be
> asynchronous
> >
> >
> > On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl  wrote:
> >
> >> The cause is the following MetaData entry in the session:
> >>
> >> class
> >>>
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
> >>
> >> On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl 
> wrote:
> >>
> >>> Hi Sven,
> >>>
> >>> I just found time to give this a try with Wicket 9.0.0-M5. There seem
> to
> >>> be issues with serialization now.
> >>>
> >>> My new config:
> >>>
> >>> protected IPageStore newCachingStore(IPageStore pageStore) {
> >>>> return new CachingPageStore(pageStore, new
> InMemoryPageStore(getName(),
> >>>> MAX_PAGES_CACHED_PER_SESSION));
> >>>> }
> >>>> protected IPageStore newPersistentStore() {
> >>>> final RedissonRedisCache redisCache = new
> >>>> RedissonRedisCache(redissonClient);
> >>>> final RedisDataStore redisDataStore = new RedisDataStore(getName(),
> >>>> redisCache, new RedisSettings());
> >>>> return new SessionQuotaManagingDataStore(redisDataStore,
> >>>> DATA_STORE_MAX_BYTES_PER_SESSION);
> >>>> }
> >>>
> >>> This exception is logged after requests:
> >>>
> >>> org.springframework.data.redis.serializer.SerializationException:
> Cannot
> >>>> serialize; nested exception is
> >>>>
> org.springframework.core.serializer.support.SerializationFailedException:
> >>>> Failed to serialize object using DefaultSerializer; nested exception
> is
> >>>> java.io.NotSerializableException:
> >>>>
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
> >>>> at
> >>>>
> org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:96)
> >>>> at
> >>>>
> org.springframework.data.redis.core.AbstractOperations.rawHashValue(AbstractOperations.java:185)
> >>>> at
> >>>>
> org.springframework.data.redis.core.DefaultHashOperations.putAll(DefaultHashOperations.java:147)
> >>>> at
> >>>>
> org.springframework.data.redis.core.DefaultBoundHashOperations.putAll(DefaultBoundHashOperations.java:147)
> >>>> at
> >>>>
> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.saveDelta(RedisIndexedSessionRepository.java:795)
> >>>> at
> >>>>
> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.save(RedisIndexedSessionRepository.java:783)
> >>>> at
> >>>>
> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.access$000(RedisIndexedSessionRepository.java:670)
> >>>> at
> >>>>
> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:398)
> >>>> at
> >>>>
> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:249)
> >>>> at
> >>>>
> com.myproject.session.InstrumentedFindByIndexNameSessionRepository.save(InstrumentedFindByIndexNameSessionRepository.java:29)
> >>>> at
> >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> >>>> Method)
> >>>> at
> >>>>
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> >>>> at
> >>>>
> java.base/jdk.internal.reflect.DelegatingMethodAccessorI

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Thomas Heigl
And one more thing. There is now a warning logged just before serialization:

WARN o.a.w.pageStore.AsynchronousPageStore: Delegated page store
> 'org.apache.wicket.pageStore.SerializingPageStore' can not be asynchronous



On Tue, Apr 7, 2020 at 2:09 PM Thomas Heigl  wrote:

> The cause is the following MetaData entry in the session:
>
> class
>> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a
>
>
> On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl  wrote:
>
>> Hi Sven,
>>
>> I just found time to give this a try with Wicket 9.0.0-M5. There seem to
>> be issues with serialization now.
>>
>> My new config:
>>
>> protected IPageStore newCachingStore(IPageStore pageStore) {
>>> return new CachingPageStore(pageStore, new InMemoryPageStore(getName(),
>>> MAX_PAGES_CACHED_PER_SESSION));
>>> }
>>> protected IPageStore newPersistentStore() {
>>> final RedissonRedisCache redisCache = new
>>> RedissonRedisCache(redissonClient);
>>> final RedisDataStore redisDataStore = new RedisDataStore(getName(),
>>> redisCache, new RedisSettings());
>>> return new SessionQuotaManagingDataStore(redisDataStore,
>>> DATA_STORE_MAX_BYTES_PER_SESSION);
>>> }
>>
>>
>> This exception is logged after requests:
>>
>> org.springframework.data.redis.serializer.SerializationException: Cannot
>>> serialize; nested exception is
>>> org.springframework.core.serializer.support.SerializationFailedException:
>>> Failed to serialize object using DefaultSerializer; nested exception is
>>> java.io.NotSerializableException:
>>> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
>>> at
>>> org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:96)
>>> at
>>> org.springframework.data.redis.core.AbstractOperations.rawHashValue(AbstractOperations.java:185)
>>> at
>>> org.springframework.data.redis.core.DefaultHashOperations.putAll(DefaultHashOperations.java:147)
>>> at
>>> org.springframework.data.redis.core.DefaultBoundHashOperations.putAll(DefaultBoundHashOperations.java:147)
>>> at
>>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.saveDelta(RedisIndexedSessionRepository.java:795)
>>> at
>>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.save(RedisIndexedSessionRepository.java:783)
>>> at
>>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.access$000(RedisIndexedSessionRepository.java:670)
>>> at
>>> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:398)
>>> at
>>> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:249)
>>> at
>>> com.myproject.session.InstrumentedFindByIndexNameSessionRepository.save(InstrumentedFindByIndexNameSessionRepository.java:29)
>>> at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>>> Method)
>>> at
>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>>> at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>> at
>>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
>>> at
>>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
>>> at
>>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>>> at
>>> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
>>> at
>>> io.micrometer.core.aop.TimedAspect.processWithTimer(TimedAspect.java:105)
>>> at io.micrometer.core.aop.TimedAspect.timedMethod(TimedAspect.java:94)
>>> at jdk.internal.reflect.GeneratedMethodAccessor146.invoke(Unknown Source)
>>> at
>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>>> at
>>> org.springframework.aop.asp

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Thomas Heigl
The cause is the following MetaData entry in the session:

class
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$1=org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$SizeLimitedData@4090594a


On Tue, Apr 7, 2020 at 1:59 PM Thomas Heigl  wrote:

> Hi Sven,
>
> I just found time to give this a try with Wicket 9.0.0-M5. There seem to
> be issues with serialization now.
>
> My new config:
>
> protected IPageStore newCachingStore(IPageStore pageStore) {
>> return new CachingPageStore(pageStore, new InMemoryPageStore(getName(),
>> MAX_PAGES_CACHED_PER_SESSION));
>> }
>> protected IPageStore newPersistentStore() {
>> final RedissonRedisCache redisCache = new
>> RedissonRedisCache(redissonClient);
>> final RedisDataStore redisDataStore = new RedisDataStore(getName(),
>> redisCache, new RedisSettings());
>> return new SessionQuotaManagingDataStore(redisDataStore,
>> DATA_STORE_MAX_BYTES_PER_SESSION);
>> }
>
>
> This exception is logged after requests:
>
> org.springframework.data.redis.serializer.SerializationException: Cannot
>> serialize; nested exception is
>> org.springframework.core.serializer.support.SerializationFailedException:
>> Failed to serialize object using DefaultSerializer; nested exception is
>> java.io.NotSerializableException:
>> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
>> at
>> org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:96)
>> at
>> org.springframework.data.redis.core.AbstractOperations.rawHashValue(AbstractOperations.java:185)
>> at
>> org.springframework.data.redis.core.DefaultHashOperations.putAll(DefaultHashOperations.java:147)
>> at
>> org.springframework.data.redis.core.DefaultBoundHashOperations.putAll(DefaultBoundHashOperations.java:147)
>> at
>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.saveDelta(RedisIndexedSessionRepository.java:795)
>> at
>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.save(RedisIndexedSessionRepository.java:783)
>> at
>> org.springframework.session.data.redis.RedisIndexedSessionRepository$RedisSession.access$000(RedisIndexedSessionRepository.java:670)
>> at
>> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:398)
>> at
>> org.springframework.session.data.redis.RedisIndexedSessionRepository.save(RedisIndexedSessionRepository.java:249)
>> at
>> com.myproject.session.InstrumentedFindByIndexNameSessionRepository.save(InstrumentedFindByIndexNameSessionRepository.java:29)
>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
>> Method)
>> at
>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> at
>> org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
>> at
>> org.springframework.aop.aspectj.MethodInvocationProceedingJoinPoint.proceed(MethodInvocationProceedingJoinPoint.java:88)
>> at
>> io.micrometer.core.aop.TimedAspect.processWithTimer(TimedAspect.java:105)
>> at io.micrometer.core.aop.TimedAspect.timedMethod(TimedAspect.java:94)
>> at jdk.internal.reflect.GeneratedMethodAccessor146.invoke(Unknown Source)
>> at
>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
>> at
>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethodWithGivenArgs(AbstractAspectJAdvice.java:644)
>> at
>> org.springframework.aop.aspectj.AbstractAspectJAdvice.invokeAdviceMethod(AbstractAspectJAdvice.java:633)
>> at
>> org.springframework.aop.aspectj.AspectJAroundAdvice.invoke(AspectJAroundAdvice.java:70)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
>> at
>> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95)
>> at
>> org.springframework.aop.framework.ReflectiveMethodInvoc

Re: Equivalent for PerSessionPageStore in Wicket 9

2020-04-07 Thread Thomas Heigl
ionRepositoryFilter.java:144)
> at
> org.springframework.session.web.http.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:82)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:193)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:166)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:202)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> at
> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:666)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:139)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:92)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:74)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
> at
> org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:373)
> at
> org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
> at
> org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:868)
> at
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1594)
> at
> org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at
> org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by:
> org.springframework.core.serializer.support.SerializationFailedException:
> Failed to serialize object using DefaultSerializer; nested exception is
> java.io.NotSerializableException:
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage
> at
> org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:68)
> at
> org.springframework.core.serializer.support.SerializingConverter.convert(SerializingConverter.java:35)
> at
> org.springframework.data.redis.serializer.JdkSerializationRedisSerializer.serialize(JdkSerializationRedisSerializer.java:94)
> ... 52 common frames omitted
> Caused by: java.io.NotSerializableException:
> org.wicketstuff.datastores.common.SessionQuotaManagingDataStore$DelegatedPage


Why does Wicket 9 try to serialize the SessionQuotaManagingDataStore in the
session? Is this intended and does DelegatePage simply need to implement
Serializable or shouldn't this be serialized at all? In Wicket 8, the
corresponding PageData wasn't serializable either so my guess would be that
this behavior is not intended.

I'm using the following config for Wicket 8 and there are no such issues:

protected IPageStore newPageStore(IDataStore dataStore) {
> final ISerializer pageSerializer = getFrameworkSettings().getSerializer();
> return new PerSessionPageStore(pageSerializer, dataStore,
> MAX_PAGES_CACHED_PER_SESSION);
> }
> protected IDataStore newDataStore() {
> final RedissonRedisCache redisCache = new
> RedissonRedisCache(redissonClient.get());
> final RedisDataStore redisDataStore = new RedisDataStore(redisCache, new
> RedisSettings());
> return new SessionQuotaManagingDataStore(redisDataStore,
> DATA_STORE_MAX_BYTES_PER_SESSION);
> }


Best regards,

Thomas

On Sat, Mar 28, 2020 at 10:23 AM Thomas Heigl  wrote:

> Thanks Sven!
>
> That looks much better. I'll give it a try as soon as I can.
>
> Best regards,
>
> Thomas
>
> On Fri, Mar 27, 2020 at 2:23 PM Sven Meier  wrote:
>
>> Hi Thomas,
>>
>> your question comes at the right time.
>>
>> I was able to improve the implementation with a new CachingPageStore:
>>
>>
>> https://github.com/apache/wicket/blob/8df3528dc44a08b7d375c20e764a3664cd6a5f30/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L145
>>
>> You can now use InMemoryPageStore as a cache too.
>>
>> Have fun
>> Sven
>>
>>
>> On 27.03.20 09:34, Sven Meier wrote:
>> > Hi Thomas,
>> >
>> > I thought I covered that usecase, but I will have to take a look.
>> >
>> > Thanks for testing Wicket 9
>> > Sven
>> >
>> > On 25.03.20 20:10, Thomas Heigl wrote:
>> >> Maybe the same approach could be used as for InSessionPageStore that
>> >> can be
>> >> used as cache and a store:
>> >>
>> >>
>> https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0
>

Re: How can a component know if it's being rendered as part of Ajax response?

2020-04-05 Thread Thomas Heigl
Hi Vit,

I'm using a utility class to encapsulate these use cases:

/** Utility class for interacting with {@link AjaxRequestTarget}s */
> public final class AjaxTarget {
> private AjaxTarget() {
> // utility class
> }
> /**
> * Checks if there is an active {@link AjaxRequestTarget}
> *
> * @return {@code true} if there is a request target bound to the thread,
> else {@code false}
> */
> public static boolean exists() {
> return find().isPresent();
> }
> /** @return the {@link AjaxRequestTarget} bound to the thread or {@code
> null} */
> public static AjaxRequestTarget get() {
> return find().orElse(null);
> }
> /** @return the optional {@link AjaxRequestTarget} bound to the thread */
> public static Optional find() {
> return RequestCycle.get().find(AjaxRequestTarget.class);
> }
> /**
> * Adds the given components to the active request target if available.
> *
> * @param component the first component to add
> * @param otherComponents the other components to add
> * @see AjaxRequestTarget#add(org.apache.wicket.Component...)
> */
> public static void add(Component component, Component... otherComponents) {
> find().ifPresent(t -> {
> if (component != null) {
> t.add(component);
> }
> t.add(otherComponents);
> });
> }
> /**
> * Adds all components of the given class to the active request target if
> available.
> *
> * @param childCriteria the child component class
> * @param  the type of child component
> * @see AjaxRequestTarget#addChildren(org.apache.wicket.MarkupContainer,
> Class)
> */
> public static  void add(Class childCriteria) {
> find().ifPresent(t -> add(t.getPage(), childCriteria));
> }
>
/**
> * Appends JavaScript to the active request target if available
> *
> * @param javaScript the script to append
> * @see AjaxRequestTarget#appendJavaScript(CharSequence)
> */
> public static void appendJavaScript(CharSequence javaScript) {
> find().ifPresent(t -> t.appendJavaScript(javaScript));
> }
> /**
> * Prepends JavaScript to the active request target if available
> *
> * @param javaScript the script to prepend
> * @see AjaxRequestTarget#prependJavaScript(CharSequence)
> */
> public static void prependJavaScript(CharSequence javaScript) {
> find().ifPresent(t -> t.prependJavaScript(javaScript));
> }

}


Best regards,

Thomas

On Sun, Apr 5, 2020 at 6:58 PM Vit Rozkovec  wrote:

> In my project it is around 40 cases of such usage. Is it little? Is it a
> lot. I don't know.
> Never mind :)
>
> Have a nice day.
> Vit
>
> On 4/5/20 11:20 AM, Sven Meier wrote:
> > Hi,
> >
> > actually it's not that common, in wicket-core and -extensions this
> > pattern is used 9 times only.
> >
> > When the RequestCycle API emerged, we decided against a specific
> > method and chose a generic one with parameter instead.
> >
> > Have fun
> > Sven
> >
> >
> > On 05.04.20 08:47, Vit Rozkovec wrote:
> >> Hi, this seems to be a frequent use case, wouldn't there be a good
> >> fit for some shorthand method?
> >>
> >> Like
> >>
> >> /getRequestCycle().onAjax(t-> {});/
> >> boolean getRequestCycle().isAjax();
> >>
> >> ?
> >>
> >> Vit
> >>
> >>
> >> On 4/4/20 11:51 PM, Sven Meier wrote:
> >>> Hi,
> >>>
> >>> you can test for the appropriate request handler:
> >>>
> >>>
> getRequestCycle().find(IPartialPageRequestHandler.class).ifPresent(target
> >>> -> /* do things on partial page update */));
> >>>
> >>> Have fun
> >>> Sven
> >>>
> >>>
> >>> On 04.04.20 23:43, Vilius Vaivada wrote:
>  Hey guys,
> 
>  I'm pretty sure I'm missing something obvious here, but I can't
>  figure out
>  a simple way for a component to contribute slightly different
>  Javascript
>  based on whether it's being rendered for a full page load or a
>  partial Ajax
>  response. Any clues?
> 
>  Thanks a lot!
> 
> >>>
> >>> -
> >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >>> For additional commands, e-mail: users-h...@wicket.apache.org
> >>>
> >>
> >>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Equivalent for PerSessionPageStore in Wicket 9

2020-03-28 Thread Thomas Heigl
Thanks Sven!

That looks much better. I'll give it a try as soon as I can.

Best regards,

Thomas

On Fri, Mar 27, 2020 at 2:23 PM Sven Meier  wrote:

> Hi Thomas,
>
> your question comes at the right time.
>
> I was able to improve the implementation with a new CachingPageStore:
>
>
> https://github.com/apache/wicket/blob/8df3528dc44a08b7d375c20e764a3664cd6a5f30/wicket-core/src/main/java/org/apache/wicket/DefaultPageManagerProvider.java#L145
>
> You can now use InMemoryPageStore as a cache too.
>
> Have fun
> Sven
>
>
> On 27.03.20 09:34, Sven Meier wrote:
> > Hi Thomas,
> >
> > I thought I covered that usecase, but I will have to take a look.
> >
> > Thanks for testing Wicket 9
> > Sven
> >
> > On 25.03.20 20:10, Thomas Heigl wrote:
> >> Maybe the same approach could be used as for InSessionPageStore that
> >> can be
> >> used as cache and a store:
> >>
> >>
> https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0
> >>
> >>
> >> On Wed, Mar 25, 2020 at 6:35 PM Thomas Heigl 
> >> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I just merged our master in our Wicket 9 branch and I ran into an
> >>> issue:
> >>>
> >>> Our current configuration with Wicket 8 looks like this:
> >>>
> >>> PageStore = PerSessionPageStore
> >>> DataStore = RedisDataStore
> >>>
> >>> So the page store keeps the last couple of pages of a session in memory
> >>> and Redis is used as a persistent store.
> >>>
> >>> I tried to recreate this behavior with Wicket 9:
> >>>
> >>> SessionStore = InMemoryPageStore
> >>> PersistentStore = RedisDataStore
> >>>
> >>> This looks correct, but it *does not work* because InMemoryPage store
> >>> implements AbstractPersistentPageStore and does *not* delegate to the
> >>> next store in the chain.
> >>>
> >>> So we basically lost the option to use a memory page store in front
> >>> of a
> >>> persistent store.
> >>>
> >>> We need this functionality because we are using Spring Session and
> >>> cannot
> >>> use the session as a page store.
> >>>
> >>> Would it be possible to add an InMemory store that delegates to the
> >>> next
> >>> store in the chain? Or do I have to implement it myself?
> >>>
> >>> Best regards,
> >>>
> >>> Thomas
> >>>
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org
> >
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: MetaData for websocket connections

2020-03-26 Thread Thomas Heigl
Hi Martin,

It is not really necessary as you pointed out, but an external registry
forces me to override the default IWebSocketConnectionRegistry so I can
update the external registry when connections are
added and removed.

If connections themselves would support metadata, there would be no need
for an external registry plus the required glue code for keeping the
registry up to date.

But if you prefer not to add functionality I can go ahead and implement an
external solution and see how it goes.

Best regards,

Thomas

On Wed, Mar 25, 2020 at 7:19 PM Martin Grigorov 
wrote:

> Hi Thomas,
>
> Is this really necessary?
> You can achieve the same today by using an external registry.
> E.g. List channels = channelRegistry.get(webSocketConnection);
> internally the registry can use WebSocketConnection's
> getApplication().getName(), getSessionId() and getKey() to construct the
> key.
>
> MetaData would do the job as well, but I'd prefer to not add more
> functionality unless really needed.
>
> Regards,
> Martin
>
> On Wed, Mar 25, 2020 at 6:30 PM Thomas Heigl  wrote:
>
> > Hi all,
> >
> > I'd like to add metadata to websocket connections. For instance, which
> > events or channels a connection is subscribed to.
> >
> > What do you think about adding MetaDataEntry[] metaData to connections
> > and setMetaData/getMetaData to IWebSocketConnection?
> >
> > Best regards,
> >
> > Thomas
> >
>


Re: Equivalent for PerSessionPageStore in Wicket 9

2020-03-25 Thread Thomas Heigl
Maybe the same approach could be used as for InSessionPageStore that can be
used as cache and a store:

https://github.com/apache/wicket/commit/894799e01227781be76886b2d1cdb2a424c812e0

On Wed, Mar 25, 2020 at 6:35 PM Thomas Heigl  wrote:

> Hi all,
>
> I just merged our master in our Wicket 9 branch and I ran into an issue:
>
> Our current configuration with Wicket 8 looks like this:
>
> PageStore = PerSessionPageStore
> DataStore = RedisDataStore
>
> So the page store keeps the last couple of pages of a session in memory
> and Redis is used as a persistent store.
>
> I tried to recreate this behavior with Wicket 9:
>
> SessionStore = InMemoryPageStore
> PersistentStore = RedisDataStore
>
> This looks correct, but it *does not work* because InMemoryPage store
> implements AbstractPersistentPageStore and does *not* delegate to the
> next store in the chain.
>
> So we basically lost the option to use a memory page store in front of a
> persistent store.
>
> We need this functionality because we are using Spring Session and cannot
> use the session as a page store.
>
> Would it be possible to add an InMemory store that delegates to the next
> store in the chain? Or do I have to implement it myself?
>
> Best regards,
>
> Thomas
>


Equivalent for PerSessionPageStore in Wicket 9

2020-03-25 Thread Thomas Heigl
Hi all,

I just merged our master in our Wicket 9 branch and I ran into an issue:

Our current configuration with Wicket 8 looks like this:

PageStore = PerSessionPageStore
DataStore = RedisDataStore

So the page store keeps the last couple of pages of a session in memory and
Redis is used as a persistent store.

I tried to recreate this behavior with Wicket 9:

SessionStore = InMemoryPageStore
PersistentStore = RedisDataStore

This looks correct, but it *does not work* because InMemoryPage store
implements AbstractPersistentPageStore and does *not* delegate to the
next store in the chain.

So we basically lost the option to use a memory page store in front of a
persistent store.

We need this functionality because we are using Spring Session and cannot
use the session as a page store.

Would it be possible to add an InMemory store that delegates to the next
store in the chain? Or do I have to implement it myself?

Best regards,

Thomas


MetaData for websocket connections

2020-03-25 Thread Thomas Heigl
Hi all,

I'd like to add metadata to websocket connections. For instance, which
events or channels a connection is subscribed to.

What do you think about adding MetaDataEntry[] metaData to connections
and setMetaData/getMetaData to IWebSocketConnection?

Best regards,

Thomas


Re: PerSessionPageStore thread-safety

2020-03-21 Thread Thomas Heigl
Hi all,

In case anyone else is running into this:

I have successfully implemented a `PageAccessSynchronizer` for Spring
Session that keeps locks in application scope. We have been running it in
production for a couple of days now and have served millions of requests
without any issues.

Spring Session with Redis adds about 3-5ms to each request for loading and
persisting the session. Together with a `PerSessionPageStore` that keeps
the last used page on each machine and avoids (de)serialization of the page
on every request this is more than acceptable in our case.

Best,

Thomas

On Fri, Feb 28, 2020 at 1:27 PM Thomas Heigl  wrote:

> Hi Martin,
>
> I created https://github.com/apache/wicket/pull/411 with my suggested
> changes. Feedback would be greatly appreciated ;)
>
> Best regards,
>
> Thomas
>
> On Fri, Feb 28, 2020 at 10:14 AM Martin Grigorov 
> wrote:
>
>> On Thu, Feb 27, 2020 at 3:58 PM Thomas Heigl  wrote:
>>
>> > Hi Martin,
>> >
>> > Could you please explain how exactly Spring Session works ? This will
>> help
>> > > us both understand where the problem comes from.
>> > >
>> >
>> > Sure.  From the docs
>> > <https://docs.spring.io/spring-session/docs/current/reference/html5/>:
>> >
>> > Spring Session provides an API and implementations for managing a user’s
>> > > session information while also making it trivial to support clustered
>> > > sessions without being tied to an application container-specific
>> > solution.
>> > > It allows replacing the HttpSession in an application
>> container-neutral
>> > > way, with support for providing session IDs in headers to work with
>> > RESTful
>> > > APIs.
>> >
>> >
>> > Spring Session basically is a servlet filter
>> > <
>> >
>> https://docs.spring.io/spring-session/docs/current/reference/html5/#httpsession-how
>> > >
>> > that looks up and persists sessions in an external store.
>> > It does so, by wrapping the servlet request and providing a custom
>> > implementation of HttpSession that keeps
>> > track of changes and persists them at the end of the request. It is
>> similar
>> > to what container-based replication
>> > does but is *independent* of the container. That's why I prefer to use
>> it
>> > instead of adding a custom session manager to Tomcat.
>> > It is much easier to customize Spring Session behavior (e.g. how cookies
>> > are stored, etc) because it is part
>> > of your application and not your container.
>> >
>> > Also how exactly do you integrate it with Wicket ? Which extension
>> > > points do you use ?
>> >
>> >
>> > There are *no* integration points with Wicket. Replacing the HttpSession
>> > with Spring Session is completely transparent.
>> > Wicket does not know anything about Spring session. The only difference
>> is
>> > that the session is not held in the containers memory,
>> > but serialized to and from an external source. I have done extensive
>> > testing and except for access synchronization everything
>> > else works as expected.
>> >
>> > Since it is backed by Redis it means that it is distributed.
>> > >
>> > But at the same time you try to use PerSessionPageStore which is
>> in-memory
>> > > store, i.e. it lives only in the memory of one of the web container
>> > nodes.
>> > > Another node has its own instance of this class.
>> >
>> >
>> > I want to use PerSessionPageStore as a local cache on each node together
>> > with sticky sessions to avoid
>> > having to go through the whole process of Redis + Deserialization for
>> every
>> > single ajax request.
>> > In a non-clustered environment or an environment where clustering is
>> done
>> > by the servlet container, Wicket
>> > can make use of the session cache that stores the last touched pages in
>> the
>> > session. In case of
>> > Spring Session, the session cache cannot be used. Sessions are
>> > (de)serialized on every request and the session
>> > cache in Wicket is transient.
>> >
>> > So strictly speaking, I don't need the PerSessionPageStore but since I
>> > cannot use the session cache, ajax requests
>> > become quite expensive. I'm using it as an application-scoped
>> alternative
>> > to the session cache.
>> >
>> > Here is how it works in normal Serv

Re: Websockets with shared resource and multiple browser tabs

2020-03-20 Thread Thomas Heigl
Hi all,

I created a ticket (https://issues.apache.org/jira/browse/WICKET-6761) and
a PR (https://github.com/apache/wicket/pull/417) for this.

Best,

Thomas

On Fri, Mar 20, 2020 at 12:14 PM Thomas Heigl  wrote:

> Hi all,
>
> I'm currently implementing native websockets for my application. I'm using
> `WebSocketResource` because I don't need access to the page and do not want
> my page to lock on websocket messages.
>
> Everything works, but I encountered one issue: It is not possible to
> support websocket connections for multiple tabs in the same browser because
> the key used for looking up the websocket connection is the name of the
> shared resource. Since this is the same for all open browser tabs, existing
> connections get overwritten when the user opens a new tab.
>
> I experimented with appending a unique token to the resource name as a
> query parameter, but then the websocket broadcaster cannot find the shared
> resource.
>
> It is possible to somehow add a shared resource that supports query
> parameters? Or is there some other way to use a separate websocket
> connection per browser tab?
>
> Thanks,
>
> Thomas
>


Websockets with shared resource and multiple browser tabs

2020-03-20 Thread Thomas Heigl
Hi all,

I'm currently implementing native websockets for my application. I'm using
`WebSocketResource` because I don't need access to the page and do not want
my page to lock on websocket messages.

Everything works, but I encountered one issue: It is not possible to
support websocket connections for multiple tabs in the same browser because
the key used for looking up the websocket connection is the name of the
shared resource. Since this is the same for all open browser tabs, existing
connections get overwritten when the user opens a new tab.

I experimented with appending a unique token to the resource name as a
query parameter, but then the websocket broadcaster cannot find the shared
resource.

It is possible to somehow add a shared resource that supports query
parameters? Or is there some other way to use a separate websocket
connection per browser tab?

Thanks,

Thomas


Re: PerSessionPageStore thread-safety

2020-02-28 Thread Thomas Heigl
Hi Martin,

I created https://github.com/apache/wicket/pull/411 with my suggested
changes. Feedback would be greatly appreciated ;)

Best regards,

Thomas

On Fri, Feb 28, 2020 at 10:14 AM Martin Grigorov 
wrote:

> On Thu, Feb 27, 2020 at 3:58 PM Thomas Heigl  wrote:
>
> > Hi Martin,
> >
> > Could you please explain how exactly Spring Session works ? This will
> help
> > > us both understand where the problem comes from.
> > >
> >
> > Sure.  From the docs
> > <https://docs.spring.io/spring-session/docs/current/reference/html5/>:
> >
> > Spring Session provides an API and implementations for managing a user’s
> > > session information while also making it trivial to support clustered
> > > sessions without being tied to an application container-specific
> > solution.
> > > It allows replacing the HttpSession in an application container-neutral
> > > way, with support for providing session IDs in headers to work with
> > RESTful
> > > APIs.
> >
> >
> > Spring Session basically is a servlet filter
> > <
> >
> https://docs.spring.io/spring-session/docs/current/reference/html5/#httpsession-how
> > >
> > that looks up and persists sessions in an external store.
> > It does so, by wrapping the servlet request and providing a custom
> > implementation of HttpSession that keeps
> > track of changes and persists them at the end of the request. It is
> similar
> > to what container-based replication
> > does but is *independent* of the container. That's why I prefer to use it
> > instead of adding a custom session manager to Tomcat.
> > It is much easier to customize Spring Session behavior (e.g. how cookies
> > are stored, etc) because it is part
> > of your application and not your container.
> >
> > Also how exactly do you integrate it with Wicket ? Which extension
> > > points do you use ?
> >
> >
> > There are *no* integration points with Wicket. Replacing the HttpSession
> > with Spring Session is completely transparent.
> > Wicket does not know anything about Spring session. The only difference
> is
> > that the session is not held in the containers memory,
> > but serialized to and from an external source. I have done extensive
> > testing and except for access synchronization everything
> > else works as expected.
> >
> > Since it is backed by Redis it means that it is distributed.
> > >
> > But at the same time you try to use PerSessionPageStore which is
> in-memory
> > > store, i.e. it lives only in the memory of one of the web container
> > nodes.
> > > Another node has its own instance of this class.
> >
> >
> > I want to use PerSessionPageStore as a local cache on each node together
> > with sticky sessions to avoid
> > having to go through the whole process of Redis + Deserialization for
> every
> > single ajax request.
> > In a non-clustered environment or an environment where clustering is done
> > by the servlet container, Wicket
> > can make use of the session cache that stores the last touched pages in
> the
> > session. In case of
> > Spring Session, the session cache cannot be used. Sessions are
> > (de)serialized on every request and the session
> > cache in Wicket is transient.
> >
> > So strictly speaking, I don't need the PerSessionPageStore but since I
> > cannot use the session cache, ajax requests
> > become quite expensive. I'm using it as an application-scoped alternative
> > to the session cache.
> >
> > Here is how it works in normal Servler environment:
> > > .
> >
> >
> > I completely agree on all your descriptions of session management in a
> > (clustered) container environment. We have
> > a shared understanding on container-based session management.
> >
> > I don't see how application-scope would help at all. As I explained
> > > earlier PageAccessSynchronizer is per o.a.w.Session instance.
> > > Maing it application-scoped will only add more concurrency issues and
> you
> > > will have to add locks on session level. At the moment it is lock-free.
> >
> >
> > There will be more concurrency, but that is not really an issue:
> >
> > The quick replacement for the PageAccessSynchronizer I wrote this morning
> > uses the following data structure:
> >
> > private static final ConcurrentMap LOCKS = new
> > > ConcurrentHashMap<>();
> >
> >
> > I made it static instead of moving it to the application, because it was
&

Re: PerSessionPageStore thread-safety

2020-02-27 Thread Thomas Heigl
 trivial to write such a global synchronizer, but it could be
much easier if some additional methods
in the default access manager were public and lock handling would be
encapsulated in an interface.

I hope I managed to explain myself. The topic is quite complex ;)

Best,

Thomas



On Thu, Feb 27, 2020 at 1:47 PM Martin Grigorov 
wrote:

> Hi Thomas,
>
> Could you please explain how exactly Spring Session works ? This will help
> us both understand where the problem comes from.
> Also how exactly do you integrate it with Wicket ? Which extension points
> do you use ?
>
> Since it is backed by Redis it means that it is distributed.
> But at the same time you try to use PerSessionPageStore which is in-memory
> store, i.e. it lives only in the memory of one of the web container nodes.
> Another node has its own instance of this class.
>
> Here is how it works in normal Servler environment:
>
> The HttpSession instances are managed by the web container, e.g. Tomcat.
> The container keeps them in memory! The container may persist them for
> failover/restart but usually the HttpSessions are kept in memory.
>
> 1) if there is just one web container node then Wicket asks the container
> for the javax.servler.HttpSession: httpServletRequest.getSession()
> Then Wicket extracts the org.apache.wicket.Session from the HttpSession
> attributes.
> The Wicket Session class has a member instance of PageAccessSynchronizer
> that is specific for the current instance of the Session.
> PageAccessSynchronizer has a Map, i.e. pageId ->
> PageLock.
> Whenever a request needs to use a specific Wicket Page then the current
> session's PageAccessSynchronizer is used to acquire a lock on it. This
> makes sure that a specific page instance is used by at most one request in
> the *current* server node.
>
> 2) if there is session replication in place, i.e. more than one server
> nodes, then:
> The web container fetches the HttpSessions for its backend. In case of
> Tomcat - it keeps the HttpSessions in memory but there is a ClusterManager
> that replicates the HttpSessions' which have been modified, i.e. their
> #setAttibute() has been called.
> In cluster mode there will be one HttpSession per server node, respectfully
> one Wicket Session instance per node, and one PageAccessSynchronizer per
> session per node.
> Using Wicket or not if you don't use sticky sessions you may face timing
> related issues in such environment. Every distributed software has this
> problem.
>
>
> On Wed, Feb 26, 2020 at 9:17 PM Thomas Heigl  wrote:
>
> > Hi Sven,
> >
> > Thanks for the link but I'm not using asynchronous serialization.
> >
> > I thought some more about the issue and I think I figured it out. My
> setup
> > looks like this:
> >
> > 1. Spring Session Redis
> > 2. [Session Cache] (Not used because it is transient and stored with
> > writeObject/readObject and does not get serialized into Redis as we do
> not
> > use Java serialization)
> > 3. PerSessionPageStore (Application-level cache held in memory)
> > 4. RedisDataStore (Synchronous)
> >
> > Observations:
> >
> > 1. If i disable second-level cache or use the serializing second-level
> > cache provided by the DefaultPageManager, there are no issues
> > 2. As soon as I enable the PerSessionPageStore we run into concurrency
> > issues
> >
> > Analysis:
> >
> > I first thought that there were some thread-safety issues
> > with PerSessionPageStore but that is not the case because even a fully
> > synchronized version shows these problems.
> >
> > The reason why disabling the 2nd-level cache or using a serializing
> variant
> > works, is because they do not operate on the same *instance* of the page.
> > Each thread gets their
> > own instance because the page is deserialized before being accessed.
> >
> > PerSessionPageStore stores the page in memory without serializing it,
> thus
> > all threads share the same instance. This is also the case when using the
> > session cache or
> > the session-based stores, but the PageAccessSynchronizer bound to the
> > session takes care of ensuring that only single request can manipulate
> the
> > page at any given time.
> >
> > So how does the synchronizer work? It keeps a Map in
> the
> > session and checks whether the page is locked on every request. In a
> > non-replicated
> > environment this works as expected as the session object lives in the
> > servlet container and is the same for each concurrent request. In my
> case,
> > the session
> > is not provided by the servlet container, but fetched from Redis by
> Spring
>

Re: PerSessionPageStore thread-safety

2020-02-27 Thread Thomas Heigl
I created https://issues.apache.org/jira/projects/WICKET/issues/WICKET-6751

Feedback would be very welcome.

Best regards,

Thomas

On Thu, Feb 27, 2020 at 10:08 AM Thomas Heigl  wrote:

> Hi all,
>
> I can confirm that my analysis was correct. I implemented a quick version
> of ApplicationScopedPageAccessSynchronizer and everything works as expected.
>
> Providing a custom PageAccessSynchronizer is very cumbersome at the
> moment. I had to override all concrete methods in the base class and
> completely
> duplicate the PageLock class because waitForRelease and markReleased have
> package visibility.
>
> I would suggest to make these two methods in PageLock public so the class
> can be reused and extract all the locking logic into an ILockManager with 3
> methods: lockPage, unlockPage, and unlockAllPages. The default lock
> manager could hold the session-scoped locks collection and custom
> implementations
> could provide their own locking mechanism.
>
> I will create a JIRA issue for this.
>
> Best regards,
>
> Thomas
>
> On Wed, Feb 26, 2020 at 8:17 PM Thomas Heigl  wrote:
>
>> Hi Sven,
>>
>> Thanks for the link but I'm not using asynchronous serialization.
>>
>> I thought some more about the issue and I think I figured it out. My
>> setup looks like this:
>>
>> 1. Spring Session Redis
>> 2. [Session Cache] (Not used because it is transient and stored with
>> writeObject/readObject and does not get serialized into Redis as we do not
>> use Java serialization)
>> 3. PerSessionPageStore (Application-level cache held in memory)
>> 4. RedisDataStore (Synchronous)
>>
>> Observations:
>>
>> 1. If i disable second-level cache or use the serializing second-level
>> cache provided by the DefaultPageManager, there are no issues
>> 2. As soon as I enable the PerSessionPageStore we run into concurrency
>> issues
>>
>> Analysis:
>>
>> I first thought that there were some thread-safety issues
>> with PerSessionPageStore but that is not the case because even a fully
>> synchronized version shows these problems.
>>
>> The reason why disabling the 2nd-level cache or using a serializing
>> variant works, is because they do not operate on the same *instance* of the
>> page. Each thread gets their
>> own instance because the page is deserialized before being accessed.
>>
>> PerSessionPageStore stores the page in memory without serializing it,
>> thus all threads share the same instance. This is also the case when using
>> the session cache or
>> the session-based stores, but the PageAccessSynchronizer bound to the
>> session takes care of ensuring that only single request can manipulate the
>> page at any given time.
>>
>> So how does the synchronizer work? It keeps a Map in
>> the session and checks whether the page is locked on every request. In a
>> non-replicated
>> environment this works as expected as the session object lives in the
>> servlet container and is the same for each concurrent request. In my case,
>> the session
>> is not provided by the servlet container, but fetched from Redis by
>> Spring Session on every request. So each concurrent thread has *their own
>> version* of the session and
>> the locks are *not shared between threads* because the session is only
>> saved back to Redis after the request has finished.
>>
>> So the problematic flow looks like this
>>
>> 1. A request comes in, we fetch the session from Redis, the request
>> acquires the session-scoped lock and starts processing
>> 2. Before the request is finished, another request comes in, fetches the
>> session from Redis, the lock map is empty because the state of request #1
>> has not been persisted to Redis
>> 3. Now both requests can modify the page and we run into concurrency
>> issues
>>
>> Summary:
>>
>> PageAccessSynchronizer does not work with Spring Session or other
>> solutions that replace the servlet container session.
>>
>> Possible solutions:
>>
>> 1. We could ensure that session locks are updated in Redis immediately
>> but that still leaves a couple of milliseconds for race conditions and adds
>> a lot of overhead
>> 2. We could use an application-scoped PageAccessSynchronizer. This solves
>> the problem as long as sessions are sticky and all concurrent requests are
>> sent to the same server.
>> 3. If we want to use non-sticky session we could use Redis locks for
>> implementing a global PageAccessSynchronizer
>>
>> I would like to go with solution #2 for now. The problem is
>

Re: PerSessionPageStore thread-safety

2020-02-27 Thread Thomas Heigl
Hi all,

I can confirm that my analysis was correct. I implemented a quick version
of ApplicationScopedPageAccessSynchronizer and everything works as expected.

Providing a custom PageAccessSynchronizer is very cumbersome at the moment.
I had to override all concrete methods in the base class and completely
duplicate the PageLock class because waitForRelease and markReleased have
package visibility.

I would suggest to make these two methods in PageLock public so the class
can be reused and extract all the locking logic into an ILockManager with 3
methods: lockPage, unlockPage, and unlockAllPages. The default lock manager
could hold the session-scoped locks collection and custom implementations
could provide their own locking mechanism.

I will create a JIRA issue for this.

Best regards,

Thomas

On Wed, Feb 26, 2020 at 8:17 PM Thomas Heigl  wrote:

> Hi Sven,
>
> Thanks for the link but I'm not using asynchronous serialization.
>
> I thought some more about the issue and I think I figured it out. My setup
> looks like this:
>
> 1. Spring Session Redis
> 2. [Session Cache] (Not used because it is transient and stored with
> writeObject/readObject and does not get serialized into Redis as we do not
> use Java serialization)
> 3. PerSessionPageStore (Application-level cache held in memory)
> 4. RedisDataStore (Synchronous)
>
> Observations:
>
> 1. If i disable second-level cache or use the serializing second-level
> cache provided by the DefaultPageManager, there are no issues
> 2. As soon as I enable the PerSessionPageStore we run into concurrency
> issues
>
> Analysis:
>
> I first thought that there were some thread-safety issues
> with PerSessionPageStore but that is not the case because even a fully
> synchronized version shows these problems.
>
> The reason why disabling the 2nd-level cache or using a serializing
> variant works, is because they do not operate on the same *instance* of the
> page. Each thread gets their
> own instance because the page is deserialized before being accessed.
>
> PerSessionPageStore stores the page in memory without serializing it, thus
> all threads share the same instance. This is also the case when using the
> session cache or
> the session-based stores, but the PageAccessSynchronizer bound to the
> session takes care of ensuring that only single request can manipulate the
> page at any given time.
>
> So how does the synchronizer work? It keeps a Map in
> the session and checks whether the page is locked on every request. In a
> non-replicated
> environment this works as expected as the session object lives in the
> servlet container and is the same for each concurrent request. In my case,
> the session
> is not provided by the servlet container, but fetched from Redis by Spring
> Session on every request. So each concurrent thread has *their own version*
> of the session and
> the locks are *not shared between threads* because the session is only
> saved back to Redis after the request has finished.
>
> So the problematic flow looks like this
>
> 1. A request comes in, we fetch the session from Redis, the request
> acquires the session-scoped lock and starts processing
> 2. Before the request is finished, another request comes in, fetches the
> session from Redis, the lock map is empty because the state of request #1
> has not been persisted to Redis
> 3. Now both requests can modify the page and we run into concurrency issues
>
> Summary:
>
> PageAccessSynchronizer does not work with Spring Session or other
> solutions that replace the servlet container session.
>
> Possible solutions:
>
> 1. We could ensure that session locks are updated in Redis immediately but
> that still leaves a couple of milliseconds for race conditions and adds a
> lot of overhead
> 2. We could use an application-scoped PageAccessSynchronizer. This solves
> the problem as long as sessions are sticky and all concurrent requests are
> sent to the same server.
> 3. If we want to use non-sticky session we could use Redis locks for
> implementing a global PageAccessSynchronizer
>
> I would like to go with solution #2 for now. The problem is
> that PageAccessSynchronizer is not an interface.
>
> Would it be possible to extract an interface so I can easily implement
> access synchronizers with different scopes?
>
> Best regards,
>
> Thomas
>
>
>
>
>
> On Wed, Feb 26, 2020 at 12:24 PM Sven Meier  wrote:
>
>> Hi Thomas,
>>
>> Im wondering whether you're running into
>> https://issues.apache.org/jira/browse/WICKET-6702
>>
>> I've been working on a solution to that problem, which is caused by pages
>> being asynchronously serialized while another request is already coming in.
>>

Re: PerSessionPageStore thread-safety

2020-02-26 Thread Thomas Heigl
Hi Sven,

Thanks for the link but I'm not using asynchronous serialization.

I thought some more about the issue and I think I figured it out. My setup
looks like this:

1. Spring Session Redis
2. [Session Cache] (Not used because it is transient and stored with
writeObject/readObject and does not get serialized into Redis as we do not
use Java serialization)
3. PerSessionPageStore (Application-level cache held in memory)
4. RedisDataStore (Synchronous)

Observations:

1. If i disable second-level cache or use the serializing second-level
cache provided by the DefaultPageManager, there are no issues
2. As soon as I enable the PerSessionPageStore we run into concurrency
issues

Analysis:

I first thought that there were some thread-safety issues
with PerSessionPageStore but that is not the case because even a fully
synchronized version shows these problems.

The reason why disabling the 2nd-level cache or using a serializing variant
works, is because they do not operate on the same *instance* of the page.
Each thread gets their
own instance because the page is deserialized before being accessed.

PerSessionPageStore stores the page in memory without serializing it, thus
all threads share the same instance. This is also the case when using the
session cache or
the session-based stores, but the PageAccessSynchronizer bound to the
session takes care of ensuring that only single request can manipulate the
page at any given time.

So how does the synchronizer work? It keeps a Map in the
session and checks whether the page is locked on every request. In a
non-replicated
environment this works as expected as the session object lives in the
servlet container and is the same for each concurrent request. In my case,
the session
is not provided by the servlet container, but fetched from Redis by Spring
Session on every request. So each concurrent thread has *their own version*
of the session and
the locks are *not shared between threads* because the session is only
saved back to Redis after the request has finished.

So the problematic flow looks like this

1. A request comes in, we fetch the session from Redis, the request
acquires the session-scoped lock and starts processing
2. Before the request is finished, another request comes in, fetches the
session from Redis, the lock map is empty because the state of request #1
has not been persisted to Redis
3. Now both requests can modify the page and we run into concurrency issues

Summary:

PageAccessSynchronizer does not work with Spring Session or other solutions
that replace the servlet container session.

Possible solutions:

1. We could ensure that session locks are updated in Redis immediately but
that still leaves a couple of milliseconds for race conditions and adds a
lot of overhead
2. We could use an application-scoped PageAccessSynchronizer. This solves
the problem as long as sessions are sticky and all concurrent requests are
sent to the same server.
3. If we want to use non-sticky session we could use Redis locks for
implementing a global PageAccessSynchronizer

I would like to go with solution #2 for now. The problem is
that PageAccessSynchronizer is not an interface.

Would it be possible to extract an interface so I can easily implement
access synchronizers with different scopes?

Best regards,

Thomas





On Wed, Feb 26, 2020 at 12:24 PM Sven Meier  wrote:

> Hi Thomas,
>
> Im wondering whether you're running into
> https://issues.apache.org/jira/browse/WICKET-6702
>
> I've been working on a solution to that problem, which is caused by pages
> being asynchronously serialized while another request is already coming in.
>
> Or maybe it is something different.
> Could you create a quickstart?
>
> Sven
>
> Am 25. Februar 2020 22:12:46 MEZ schrieb Thomas Heigl  >:
> >Hi again,
> >
> >I investigated a bit and it does not seem to have anything to do with
> >the
> >PerSessionPageStore. I implemented a completely synchronized version of
> >it
> >and the problems still exist.
> >
> >If I switch to the default second-level cache that stores serialized
> >pages
> >in application scope, everything works as expected. Only the
> >non-serialized
> >pages in PerSessionPageStore seem to be affected by concurrent ajax
> >modifications.
> >
> >What is the difference between keeping pages in the session and keeping
> >the
> >same pages in the PerSessionPageStore? Is there some additional locking
> >done for pages in the session?
> >
> >Best,
> >
> >Thomas
> >
> >On Tue, Feb 25, 2020 at 8:25 PM Thomas Heigl 
> >wrote:
> >
> >> Hi all,
> >>
> >> I'm currently experimenting with PerSessionPageStore as a
> >second-level
> >> cache. We are moving our page store from memory (i.e. session) to
> >Redis and
> >> ke

Re: PerSessionPageStore thread-safety

2020-02-25 Thread Thomas Heigl
Hi again,

I investigated a bit and it does not seem to have anything to do with the
PerSessionPageStore. I implemented a completely synchronized version of it
and the problems still exist.

If I switch to the default second-level cache that stores serialized pages
in application scope, everything works as expected. Only the non-serialized
pages in PerSessionPageStore seem to be affected by concurrent ajax
modifications.

What is the difference between keeping pages in the session and keeping the
same pages in the PerSessionPageStore? Is there some additional locking
done for pages in the session?

Best,

Thomas

On Tue, Feb 25, 2020 at 8:25 PM Thomas Heigl  wrote:

> Hi all,
>
> I'm currently experimenting with PerSessionPageStore as a second-level
> cache. We are moving our page store from memory (i.e. session) to Redis and
> keeping 1-2 pages per session in memory speeds up ajax requests quite a bit
> because network roundtrips and (de)serialization can be skipped for cached
> pages.
>
> Our application is very ajax heavy (it is basically a single page
> application with lots of lazy-loading). While rapidly clicking around and
> firing as many parallel ajax requests as possible, I noticed that it is
> quite easy to trigger exceptions that I have never seen before.
> ConcurrentModificationExceptions during serialization,
> MarkupNotFoundExceptions, exceptions about components already dequeuing etc.
>
> So I had a look at the implementation of PerSessionPageStore and noticed
> that is does not do any kind of synchronization and does not use atomic
> operations when updating the cache. It seems to me that the second-level
> cache is not really usable in a concurrent ajax environment.
>
> I think that writing pages to the second level cache store should either
> synchronize on sessionId+pageId or attempt to use atomic operations
> provided by ConcurrentHashMap.
>
> Did anyone else ever run into these issues? The code
> of PerSessionPageStore is quite complex because of soft references,
> skip-list maps etc. so I'm not sure what the right approach to address
> these problems would be.
>
> Best regards,
>
> Thomas
>


PerSessionPageStore thread-safety

2020-02-25 Thread Thomas Heigl
Hi all,

I'm currently experimenting with PerSessionPageStore as a second-level
cache. We are moving our page store from memory (i.e. session) to Redis and
keeping 1-2 pages per session in memory speeds up ajax requests quite a bit
because network roundtrips and (de)serialization can be skipped for cached
pages.

Our application is very ajax heavy (it is basically a single page
application with lots of lazy-loading). While rapidly clicking around and
firing as many parallel ajax requests as possible, I noticed that it is
quite easy to trigger exceptions that I have never seen before.
ConcurrentModificationExceptions during serialization,
MarkupNotFoundExceptions, exceptions about components already dequeuing etc.

So I had a look at the implementation of PerSessionPageStore and noticed
that is does not do any kind of synchronization and does not use atomic
operations when updating the cache. It seems to me that the second-level
cache is not really usable in a concurrent ajax environment.

I think that writing pages to the second level cache store should either
synchronize on sessionId+pageId or attempt to use atomic operations
provided by ConcurrentHashMap.

Did anyone else ever run into these issues? The code of PerSessionPageStore
is quite complex because of soft references, skip-list maps etc. so I'm not
sure what the right approach to address these problems would be.

Best regards,

Thomas


Re: Java 8 access to effectively final variables/method parameters from anonymous classes

2019-08-04 Thread Thomas Heigl
>
> Would you mind to elaborate on this a bit? What do you do in your forms?
> How do you handle state there? Do you use view models that are
> serializable? Do you keep state in local variables and propagate it to the
> domain object in every request after it is reloaded?


Sure.

We use DTOs/View Models for most of our forms. We started out with
manipulating domain objects directly, but it caused too many headaches with
serialization and detaching/re-attaching entities etc.
Domain objects are only used as Wicket (loadable detachable) models when
the manipulation is just a single step that can be persisted to the DB
right away. Your ajax link is a good example. Also single-page forms where
the final "Save/Next" button persists the changes to the DB. Whenever we
have a multi-step process (like a wizard) for creating or editing domain
objects, we use custom view models.

Thomas

On Sun, Aug 4, 2019 at 11:53 AM mscoon  wrote:

> Hi,
>
> If you don't mind me following up on your comment...
>
>
> > Personally, I rarely encounter serialization issues. None of our domain
> > objects implement Serializable. They can only be used with
> > LoadableDetachableModels that only store the identifier.
> >
> >>
> >>
> Would you mind to elaborate on this a bit? What do you do in your forms?
> How do you handle state there? Do you use view models that are
> serializable? Do you keep state in local variables and propagate it to the
> domain object in every request after it is reloaded?
>
> We often use serializable domain objects so that keeping state on the
> object is simple. For example if you have an ajax link that increments a
> property of the domain object, you simply increment the property and rely
> on the object being serialized for keeping state.
>
> Cheers
> Marios
>


Re: Java 8 access to effectively final variables/method parameters from anonymous classes

2019-08-04 Thread Thomas Heigl
The IntelliJ inspection has configuration options. If you enable only the
last option "Report variables which are implicitly final", it might help
with your problem:

[image: image.png]

Personally, I rarely encounter serialization issues. None of our domain
objects implement Serializable. They can only be used with
LoadableDetachableModels that only store the identifier.

If you have some serializable objects that you never want to serialize in
Wicket, you can implement a custom serializer that checks and logs an error
or throws if such objects are serialized (e.g. JPA entities).

-t

On Sun, Aug 4, 2019 at 10:44 AM mscoon  wrote:

> Thank you for your answer Thomas.
>
> "Local variable or parameter can be final" inspection actually does
> something different. It will warn that a parameter can be made final when
> its value does not change, even if it not used in an anonymous class. This
> will result in programmers declaring all variables that they can as final
> and using them in the anonymous classes, which will again result in the
> same serialization oversights I mentioned...
>
> The same applies to checkstyle.
>
> I wonder why this is not a problem for others using wicket. Given wicket's
> serialization, since java 8 that allowed anonymous classes to access
> variables from the enclosing scope even if they are not declared final, I
> find there is a lot of room for unintentionally serializing stuff that you
> didn't want/notice is being serialized... Perhaps we are doing something
> wrong...
>
>
> On Sun, Aug 4, 2019 at 11:35 AM Thomas Heigl  wrote:
>
> > Hi Marios,
> >
> > I don't think there is a way to disable this behaviour but you have other
> > options:
> >
> > - If you use IntelliJ, you can configure the "Local variable or parameter
> > can be final" inspection to raise an error instead of a warning (for
> > variables that are implicitly final)
> > - Checkstyle or similar tools that you can hook into your build process
> > might have similar inspections
> >
> > Best,
> >
> > Thomas
> >
> > On Sun, Aug 4, 2019 at 9:18 AM mscoon  wrote:
> >
> > > Hi all,
> > >
> > > Java 8 introduced the ability to access effectively final
> > variables/method
> > > parameters from anonymous classes without having to add explicitly the
> > > "final" keyword.
> > >
> > > This has resulted in a lot of cases where the programmer does not
> notice
> > > that they are referencing a model object from an anonymous class, which
> > > results in the model object being serialized.
> > >
> > > Example:
> > > code inside a hypothetical MyPanel.newLink() method...
> > >
> > > Myclass obj = getModelObject();
> > > return new AjaxLink("link") {
> > > void onClick(AjaxRequestTarget t) {
> > >  if (obj.getId() != null) {
> > >// do something
> > >  } else {
> > >   // do something else
> > >  }
> > > }
> > >
> > > In previous java versions you'd have to declare obj as final, and this
> > > would help you notice that it is going to be serialized.
> > >
> > > I understand that it is easy to change the code and avoid obj being
> > > serialized. The problem is not how to fix the code - the problem is
> that
> > > this "problem" often goes unnoticed.
> > >
> > > As far as I have searched, there is no way to disable this behavior
> (not
> > > having to explicitly declare variables as final) in java 8.
> > >
> > > Do you have any suggestions on how to handle this?
> > >
> > > Thank you in advance,
> > > Marios
> > >
> >
>


Re: Programmatic creation of messages with nested components

2019-08-04 Thread Thomas Heigl
Hi Sven,

I came to the same conclusion trying to refactor WicketMessageResolver.

I have previously used different fragments and panels to solve this issue
but it is annoying because you end up with lots of additional code and HTML
that only differs in the message key.

My solution now was to copy the whole WicketMessageResolver to my project,
delete everything related to handling the custom Wicket tag and calling it
WicketMessageContainer.

Best,

Thomas

On Sun, Jul 28, 2019 at 11:02 PM Sven Meier  wrote:

> Hi Thomas,
>
> WicketMessageResolver has a lot of magic and I find it hard to decide
> which of these could be extracted into a stand-alone component (e.g.
> resolving properties from the parents model.
>
> My question: Why don't you use a Panel instead, using different markup
> based on some condition?
>
> Have fun
> Sven
>
>
> On 27.07.19 16:16, Thomas Heigl wrote:
> > Hi all,
> >
> > I just gave this a try by copying the whole `MessageContainer` class to
> my
> > project and using it like this:
> >
> > final MessageContainer c = new MessageContainer("msg", "test.msg",
> false);
> >> c.add(new ExternalLink("link", Model.of("http://test.com;), new
> >> StringResourceModel("test.link")));
> >> add(c);
> >
> > This fails with a NPE because the MessageContainer assumes, that it has
> to
> > use its parent component for resolving any nested components, because the
> > `` tag is not a container by itself:
> >
> > Component component = getParent().get(id);
> >> if (component == null) {
> >> component = ComponentResolvers.resolve(getParent(), markupStream,
> >> currentTag, null);
> >  // Must not be a Page and it must be connected to a parent.
> >> if (component.getParent() == null) {
> >> component = null;
> >> }
> > }
> >
> >
> > When used with a `` or a ``
> the
> > tag component itself has to be used to resolve nested components. It is
> > possible to fix this by replacing all calls to `getParent()` with a
> custom
> > method that checks if the tag is a wicket message or some other element,
> > but it does not feel right.
> >
> > I could go ahead with my local copy of MessageContainer and adjust it for
> > my project but it contains a lot of logic that has to be duplicated like
> > message interpolation and markup stream parsing.
> >
> > I'd be willing to provide a PR if someone in the development team has any
> > suggestions on how to approach this.
> >
> > Best,
> >
> > Thomas
> >
> >
> >
> > On Thu, Jul 25, 2019 at 9:17 AM Thomas Heigl 
> wrote:
> >
> >> Hi Martin,
> >>
> >> Sure. Currently I'm using  like described in the JavaDoc
> >> of WicketMessageResolver:
> >>
> >> Template:
> >>
> >>>
> >>>  [amount].
> >>>  
> >>>  
> >>>  
> >>> 
> >>
> >> Java:
> >>
> >>> add(new Label("amount", new Model("$5.00")));
> >>> add(new BookmarkablePageLink("link", DetailsPage.class));
> >>
> >> i18n:
> >>
> >>> myKey=Your balance is ${amount}. Click ${link} to view the details.
> >>> linkText=here
> >>
> >> This works, but the key "myKey" cannot be changed during runtime. I'd
> like
> >> to use the private MessageContainer the same way I can use an
> >> EnclosureContainer:
> >>
> >> Template:
> >>
> >>>
> >>>  [amount].
> >>>  
> >>>  
> >>>  
> >>> 
> >>
> >> Java:
> >>
> >>> final String key = "myKey";
> >> final MessageContainer msg = new MessageContainer("msg", key, true);
> >>
> >> msg.add(new Label("amount", new Model("$5.00")));
> >>> msg.add(new BookmarkablePageLink("link", DetailsPage.class));
> >> add(msg);
> >>
> >>
> >> I hope that explains my requirement a bit better.
> >>
> >> Best,
> >>
> >>   Thomas
> >>
> >>
> >> On Thu, Jul 25, 2019 at 6:48 AM Martin Terra <
> >> martin.te...@koodaripalvelut.com> wrote:
> >>
> >>> Hi!
> >>>
> >>> Can you show an example of solution now vs. solutio

Re: Java 8 access to effectively final variables/method parameters from anonymous classes

2019-08-04 Thread Thomas Heigl
Hi Marios,

I don't think there is a way to disable this behaviour but you have other
options:

- If you use IntelliJ, you can configure the "Local variable or parameter
can be final" inspection to raise an error instead of a warning (for
variables that are implicitly final)
- Checkstyle or similar tools that you can hook into your build process
might have similar inspections

Best,

Thomas

On Sun, Aug 4, 2019 at 9:18 AM mscoon  wrote:

> Hi all,
>
> Java 8 introduced the ability to access effectively final variables/method
> parameters from anonymous classes without having to add explicitly the
> "final" keyword.
>
> This has resulted in a lot of cases where the programmer does not notice
> that they are referencing a model object from an anonymous class, which
> results in the model object being serialized.
>
> Example:
> code inside a hypothetical MyPanel.newLink() method...
>
> Myclass obj = getModelObject();
> return new AjaxLink("link") {
> void onClick(AjaxRequestTarget t) {
>  if (obj.getId() != null) {
>// do something
>  } else {
>   // do something else
>  }
> }
>
> In previous java versions you'd have to declare obj as final, and this
> would help you notice that it is going to be serialized.
>
> I understand that it is easy to change the code and avoid obj being
> serialized. The problem is not how to fix the code - the problem is that
> this "problem" often goes unnoticed.
>
> As far as I have searched, there is no way to disable this behavior (not
> having to explicitly declare variables as final) in java 8.
>
> Do you have any suggestions on how to handle this?
>
> Thank you in advance,
> Marios
>


Re: Programmatic creation of messages with nested components

2019-07-27 Thread Thomas Heigl
Hi all,

I just gave this a try by copying the whole `MessageContainer` class to my
project and using it like this:

final MessageContainer c = new MessageContainer("msg", "test.msg", false);
> c.add(new ExternalLink("link", Model.of("http://test.com;), new
> StringResourceModel("test.link")));
> add(c);


This fails with a NPE because the MessageContainer assumes, that it has to
use its parent component for resolving any nested components, because the
`` tag is not a container by itself:

Component component = getParent().get(id);
> if (component == null) {
> component = ComponentResolvers.resolve(getParent(), markupStream,
> currentTag, null);

// Must not be a Page and it must be connected to a parent.
> if (component.getParent() == null) {
> component = null;
> }

}


When used with a `` or a `` the
tag component itself has to be used to resolve nested components. It is
possible to fix this by replacing all calls to `getParent()` with a custom
method that checks if the tag is a wicket message or some other element,
but it does not feel right.

I could go ahead with my local copy of MessageContainer and adjust it for
my project but it contains a lot of logic that has to be duplicated like
message interpolation and markup stream parsing.

I'd be willing to provide a PR if someone in the development team has any
suggestions on how to approach this.

Best,

Thomas



On Thu, Jul 25, 2019 at 9:17 AM Thomas Heigl  wrote:

> Hi Martin,
>
> Sure. Currently I'm using  like described in the JavaDoc
> of WicketMessageResolver:
>
> Template:
>
>>   
>> [amount].
>> 
>> 
>> 
>>
>
>
> Java:
>
>> add(new Label("amount", new Model("$5.00")));
>> add(new BookmarkablePageLink("link", DetailsPage.class));
>
>
> i18n:
>
>> myKey=Your balance is ${amount}. Click ${link} to view the details.
>> linkText=here
>
>
> This works, but the key "myKey" cannot be changed during runtime. I'd like
> to use the private MessageContainer the same way I can use an
> EnclosureContainer:
>
> Template:
>
>>   
>> [amount].
>> 
>> 
>> 
>>
>
>
> Java:
>
>> final String key = "myKey";
>
> final MessageContainer msg = new MessageContainer("msg", key, true);
>
> msg.add(new Label("amount", new Model("$5.00")));
>> msg.add(new BookmarkablePageLink("link", DetailsPage.class));
>
> add(msg);
>
>
> I hope that explains my requirement a bit better.
>
> Best,
>
>  Thomas
>
>
> On Thu, Jul 25, 2019 at 6:48 AM Martin Terra <
> martin.te...@koodaripalvelut.com> wrote:
>
>> Hi!
>>
>> Can you show an example of solution now vs. solution after change, what
>> are
>> the benefits of such visibility change to your case? Maybe there is
>> another
>> way to accomplish your goal?
>>
>> **
>> Martin
>>
>> ke 24. heinäk. 2019 klo 22.25 Thomas Heigl (tho...@umschalt.com)
>> kirjoitti:
>>
>> > Hi all,
>> >
>> > I'd like to create Wicket messages with child components
>> programatically.
>> > Currently, this is only possible by using the  tag and
>> > nesting components inside of it.
>> >
>> > For most use cases this is sufficient, but I sometimes come across cases
>> > where I'd like to programatically define the message key instead of
>> > hard-coding it in the template.
>> >
>> > The class that does all the interpolation is currently
>> > private:
>> > org.apache.wicket.markup.resolver.WicketMessageResolver.MessageContainer
>> >
>> > Would it be possible to make this a public (top-level) class in Wicket
>> 9?
>> > If I understand correctly, this would solve my requirement without any
>> > other code changes.
>> >
>> > Best regards,
>> >
>> > Thomas
>> >
>>
>


Re: Programmatic creation of messages with nested components

2019-07-25 Thread Thomas Heigl
Hi Martin,

Sure. Currently I'm using  like described in the JavaDoc of
WicketMessageResolver:

Template:

>   
> [amount].
> 
> 
> 
>


Java:

> add(new Label("amount", new Model("$5.00")));
> add(new BookmarkablePageLink("link", DetailsPage.class));


i18n:

> myKey=Your balance is ${amount}. Click ${link} to view the details.
> linkText=here


This works, but the key "myKey" cannot be changed during runtime. I'd like
to use the private MessageContainer the same way I can use an
EnclosureContainer:

Template:

>   
> [amount].
> 
> 
> 
>


Java:

> final String key = "myKey";

final MessageContainer msg = new MessageContainer("msg", key, true);

msg.add(new Label("amount", new Model("$5.00")));
> msg.add(new BookmarkablePageLink("link", DetailsPage.class));

add(msg);


I hope that explains my requirement a bit better.

Best,

 Thomas


On Thu, Jul 25, 2019 at 6:48 AM Martin Terra <
martin.te...@koodaripalvelut.com> wrote:

> Hi!
>
> Can you show an example of solution now vs. solution after change, what are
> the benefits of such visibility change to your case? Maybe there is another
> way to accomplish your goal?
>
> **
> Martin
>
> ke 24. heinäk. 2019 klo 22.25 Thomas Heigl (tho...@umschalt.com)
> kirjoitti:
>
> > Hi all,
> >
> > I'd like to create Wicket messages with child components programatically.
> > Currently, this is only possible by using the  tag and
> > nesting components inside of it.
> >
> > For most use cases this is sufficient, but I sometimes come across cases
> > where I'd like to programatically define the message key instead of
> > hard-coding it in the template.
> >
> > The class that does all the interpolation is currently
> > private:
> > org.apache.wicket.markup.resolver.WicketMessageResolver.MessageContainer
> >
> > Would it be possible to make this a public (top-level) class in Wicket 9?
> > If I understand correctly, this would solve my requirement without any
> > other code changes.
> >
> > Best regards,
> >
> > Thomas
> >
>


Programmatic creation of messages with nested components

2019-07-24 Thread Thomas Heigl
Hi all,

I'd like to create Wicket messages with child components programatically.
Currently, this is only possible by using the  tag and
nesting components inside of it.

For most use cases this is sufficient, but I sometimes come across cases
where I'd like to programatically define the message key instead of
hard-coding it in the template.

The class that does all the interpolation is currently
private: 
org.apache.wicket.markup.resolver.WicketMessageResolver.MessageContainer

Would it be possible to make this a public (top-level) class in Wicket 9?
If I understand correctly, this would solve my requirement without any
other code changes.

Best regards,

Thomas


Re: HttpSessionDataStore in Wicket 9

2019-04-23 Thread Thomas Heigl
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 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  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  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
>>
>>


Re: HttpSessionDataStore in Wicket 9

2019-04-23 Thread Thomas Heigl
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  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  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
>
>


Re: Untouching pages in Wicket 9

2019-04-23 Thread Thomas Heigl
Hi Sven,

I have some types of ajax behavior callback (timers, lazy-loading) that do
not really touch the page and I want to avoid serialization.

It's basically the same use case as the original ticket:
https://issues.apache.org/jira/browse/WICKET-5933

It would be great if we had some mechanism to mark a request as
"non-touching" in Wicket 9.  Either via "getPageManager().untouch()" or
some other mechanism.

Best,

Thomas

On Tue, Apr 23, 2019 at 1:44 PM Sven Meier  wrote:

>
>
> Hi Thomas,
>
>
>
> you're right, that method is no longer available.
>
>
>
> What do you use it for? Do you want to throw away the current page
> changes, but still keep an older state in the persistent page store?
>
>
>
> Thanks
>
> Sven
>
>
>
>
>
>
>
>
>
> >
> > On 22.04.2019 at 19:19,wrote:
> >
> >
> >  Hi all, What is the equivalent of the following line in Wicket 9?
> Session.get().getPageManager().untouch(content.getPage()) There is only
> `removePage` now, but it doesn't do the same thing as far as I can see. Is
> it still possible to untouch pages in ajax requests so they won't be
> serialized again? Best, Thomas
> >
>


Re: HttpSessionDataStore in Wicket 9

2019-04-23 Thread 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  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
> >
>


Untouching pages in Wicket 9

2019-04-22 Thread Thomas Heigl
Hi all,

What is the equivalent of the following line in Wicket 9?

Session.get().getPageManager().untouch(content.getPage())


There is only `removePage` now, but it doesn't do the same thing as far as
I can see. Is it still possible to untouch pages in ajax requests so they
won't be serialized again?

Best,

Thomas


HttpSessionDataStore in Wicket 9

2019-04-22 Thread 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: Seeking help for a HotSwapAgent's Wicket plugin

2018-07-16 Thread Thomas Heigl
Hi Francesco,

Do you have the appropriate Wicket settings enabled?

I'm using this configuration in development mode:

private static void initResourceSettings(WebApplication app) {
> final ResourceSettings resourceSettings = app.getResourceSettings();
> if (!isDeployment(app)) {
> resourceSettings.setDefaultCacheDuration(Duration.seconds(0));
> resourceSettings.setResourcePollFrequency(Duration.seconds(5));
> }
> }


Best,

Thomas

On Mon, Jul 16, 2018 at 1:54 PM, Francesco Chicchiriccò  wrote:

> Hi Thomas,
> thanks for your reply.
>
> I have taken your WicketPlugin, reworked it a bit and generated
>
> https://gist.github.com/ilgrosso/c12fa371a5033de1e92b0a35115b6456
>
> Unfortunately, it does not seem to work: once started Tomcat with
> hotswap-agent enabled, I can successfully reload Java classes, but changes
> to properties files just have no effect.
>
> I have also been debugging the WicketPlugin class, and I can see that the
> Command is effectively invoked and completes with no exceptions.
>
> What could I be missing? Also, do you have any idea why I don't get any
> change in HTML files reloaded? I have added my src/main/resources folder to
> extraClassPath as you did.
>
> Maybe something missing in my WicketApplications' settings?
>
> Thanks for your support.
> Regards.
>
> On 2018/07/13 16:50:16, Thomas Heigl  wrote:
> > Hi Francesco,
> >
> > I faced the same situation last week.
> >
> > I wrote a Wicket plugin that clears the Localizer cache. It does not
> clear
> > the resource bundle cache because I use Spring's
> ReloadableResourceBundle,
> > but that should be very easy to add.
> >
> > Configuration is a little more difficult than with JRebel. I had to add
> > src/main/resources as extraClasspath for some reason, to get it to reload
> > HTML and property files.
> >
> > Here is a gist with my Wicket plugin and my working
> > hotswap-agent.properties:
> >
> > https://gist.github.com/theigl/6ff4a505eac8f166b9bd079017884474
> >
> > Best,
> >
> > Thomas
> >
> > On Fri, Jul 13, 2018 at 4:53 PM, Francesco Chicchiriccò <
> ilgro...@apache.org
> > > wrote:
> >
> > > Hi all,
> > > at Syncope we recently switched from JRebel to HotSwapAgent, mostly
> > > because the MyJRebel program has ended.
> > > All works quite well for Java classes, but we do have issues with HTML
> and
> > > properties files (for Resource Bundles) used by Wicket.
> > >
> > > Please consider that we do package our Wicket application as JAR with
> > > web-fragment [1], and HTML and properties files are kept under
> > > src/main/resources [2].
> > >
> > > I have started building a Wicket plugin for HotSwapAgent following the
> > > instructions at [3] and the samples at [4]: the MyFaces plugin [5]
> looks
> > > promising, at least because it says that it's clearing out the Resource
> > > Bundle cache.
> > >
> > > So my question is: assuming that HotSwapAgent correctly replaces the
> HTML
> > > and properties file in the classloader, how can I trigger Wicket to
> reload?
> > >
> > > TIA
> > > Regards.
> > >
> > > [1] https://github.com/apache/syncope/tree/master/client/console
> > > [2] https://github.com/apache/syncope/tree/master/client/
> > > console/src/main/resources/org/apache/syncope/client/console
> > > [3] http://hotswapagent.org/mydoc_custom_plugins.html
> > > [4] https://github.com/HotswapProjects/HotswapAgent/
> > > blob/master/README.md#java-frameworks-plugins
> > > [5] https://github.com/HotswapProjects/HotswapAgent/
> > > blob/master/plugin/hotswap-agent-myfaces-plugin/src/main/
> > > java/org/hotswap/agent/plugin/myfaces/MyFacesPlugin.java
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Seeking help for a HotSwapAgent's Wicket plugin

2018-07-13 Thread Thomas Heigl
Hi Francesco,

I faced the same situation last week.

I wrote a Wicket plugin that clears the Localizer cache. It does not clear
the resource bundle cache because I use Spring's ReloadableResourceBundle,
but that should be very easy to add.

Configuration is a little more difficult than with JRebel. I had to add
src/main/resources as extraClasspath for some reason, to get it to reload
HTML and property files.

Here is a gist with my Wicket plugin and my working
hotswap-agent.properties:

https://gist.github.com/theigl/6ff4a505eac8f166b9bd079017884474

Best,

Thomas

On Fri, Jul 13, 2018 at 4:53 PM, Francesco Chicchiriccò  wrote:

> Hi all,
> at Syncope we recently switched from JRebel to HotSwapAgent, mostly
> because the MyJRebel program has ended.
> All works quite well for Java classes, but we do have issues with HTML and
> properties files (for Resource Bundles) used by Wicket.
>
> Please consider that we do package our Wicket application as JAR with
> web-fragment [1], and HTML and properties files are kept under
> src/main/resources [2].
>
> I have started building a Wicket plugin for HotSwapAgent following the
> instructions at [3] and the samples at [4]: the MyFaces plugin [5] looks
> promising, at least because it says that it's clearing out the Resource
> Bundle cache.
>
> So my question is: assuming that HotSwapAgent correctly replaces the HTML
> and properties file in the classloader, how can I trigger Wicket to reload?
>
> TIA
> Regards.
>
> [1] https://github.com/apache/syncope/tree/master/client/console
> [2] https://github.com/apache/syncope/tree/master/client/
> console/src/main/resources/org/apache/syncope/client/console
> [3] http://hotswapagent.org/mydoc_custom_plugins.html
> [4] https://github.com/HotswapProjects/HotswapAgent/
> blob/master/README.md#java-frameworks-plugins
> [5] https://github.com/HotswapProjects/HotswapAgent/
> blob/master/plugin/hotswap-agent-myfaces-plugin/src/main/
> java/org/hotswap/agent/plugin/myfaces/MyFacesPlugin.java
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: ChainingModel warnings in Wicket 8

2018-06-10 Thread Thomas Heigl
Hi Maxim,

Created https://issues.apache.org/jira/browse/WICKET-6560.

Thomas

On Sat, Jun 9, 2018 at 5:44 AM, Maxim Solodovnik 
wrote:

> Sounds like these 2 comments worth JIRA
> Or Jira+PR ;))
>
> On Thu, Jun 7, 2018 at 9:45 PM, Thomas Heigl  wrote:
> > Also the warning is logged for `null` objects, which probably shouldn't
> > happen.
> >
> > public ChainingModel(final Object modelObject)
> >> {
> >> if (modelObject instanceof Session)
> >> {
> >> LOG.warn("It is not a good idea to reference the .");
> >> } else if (modelObject instanceof Serializable == false)
> >> {
> >> LOG.warn("It is not a good idea to reference a non-serializable
> >> instance ");
> >> }
> >> target = modelObject;
> >> }
> >
> >
> > It should read something like:
> >
> > if (modelObject != null && modelObject instanceof Serializable == false)
> >
> >
> > Best,
> >
> > Thomas
> >
> >
> > On Thu, Jun 7, 2018 at 4:25 PM, Thomas Heigl 
> wrote:
> >
> >> Hi all,
> >>
> >> After porting our app to Wicket 8, I'm getting these warnings on my test
> >> environment:
> >>
> >> WAR o.a.w.model.ChainingModel It is not a good idea to reference a
> >>> non-serializable instance in models directly as it may lead to
> >>> serialization problems
> >>
> >>
> >> The warning is OK, but it gives me absolutely no hint where to look for
> >> the issue. Could someone please add the (simple) class name of the model
> >> object to the warning message?
> >>
> >> Currently, the only way for me to find these issues is with a breakpoint
> >> in `ChainingModel` and clicking through my application until I hit the
> >> warning.
> >>
> >> Best,
> >>
> >> Thomas
> >>
>
>
>
> --
> WBR
> Maxim aka solomax
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: ChainingModel warnings in Wicket 8

2018-06-07 Thread Thomas Heigl
Also the warning is logged for `null` objects, which probably shouldn't
happen.

public ChainingModel(final Object modelObject)
> {
> if (modelObject instanceof Session)
> {
> LOG.warn("It is not a good idea to reference the .");
> } else if (modelObject instanceof Serializable == false)
> {
> LOG.warn("It is not a good idea to reference a non-serializable
> instance ");
> }
> target = modelObject;
> }


It should read something like:

if (modelObject != null && modelObject instanceof Serializable == false)


Best,

Thomas


On Thu, Jun 7, 2018 at 4:25 PM, Thomas Heigl  wrote:

> Hi all,
>
> After porting our app to Wicket 8, I'm getting these warnings on my test
> environment:
>
> WAR o.a.w.model.ChainingModel It is not a good idea to reference a
>> non-serializable instance in models directly as it may lead to
>> serialization problems
>
>
> The warning is OK, but it gives me absolutely no hint where to look for
> the issue. Could someone please add the (simple) class name of the model
> object to the warning message?
>
> Currently, the only way for me to find these issues is with a breakpoint
> in `ChainingModel` and clicking through my application until I hit the
> warning.
>
> Best,
>
> Thomas
>


ChainingModel warnings in Wicket 8

2018-06-07 Thread Thomas Heigl
Hi all,

After porting our app to Wicket 8, I'm getting these warnings on my test
environment:

WAR o.a.w.model.ChainingModel It is not a good idea to reference a
> non-serializable instance in models directly as it may lead to
> serialization problems


The warning is OK, but it gives me absolutely no hint where to look for the
issue. Could someone please add the (simple) class name of the model object
to the warning message?

Currently, the only way for me to find these issues is with a breakpoint in
`ChainingModel` and clicking through my application until I hit the warning.

Best,

Thomas


Re: Release WiQuery for Wicket 8

2018-06-07 Thread Thomas Heigl
Hi Emond,

I did some exploratory testing against the current build. I checked Dialog,
Autocomplete, Accordion, Slider, Sortable, and Tooltip and all seem to be
working at first glance.

All my tests pass as well.

Best,

Thomas

On Wed, Jun 6, 2018 at 1:07 PM, Emond Papegaaij 
wrote:

> I've fixed the problem. The setup currently used is discouraged and broken
> in
> m2e, but I don't feel like restructuring the whole thing to get rid of
> this
> test-jar.
>
> Emond
>
> On woensdag 6 juni 2018 11:57:43 CEST Thomas Heigl wrote:
> > The culprit is:
> >
> > https://github.com/wicketstuff/wiquery/commit/
> 0235691174ceeede22b588d2f67868
> > b940d9be3a
> > On Wed, Jun 6, 2018 at 11:51 AM, Thomas Heigl 
> wrote:
> > > `mvn clean install` fails for me because no test-jar is built for the
> core
> > > module:
> > >
> > > [INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS [
> > >
> > >>  0.353 s]
> > >>
> > >> [INFO] WiQuery Core Project ... SUCCESS [
> > >>
> > >>  2.673 s]
> > >>
> > >> [INFO] WiQuery jQuery UI Project .. FAILURE [
> > >>
> > >>  0.023 s]
> > >>
> > >> [INFO] WiQuery Demo Project 8.0-SNAPSHOT .. SKIPPED
> > >> [INFO] 
> > >> 
> > >> [INFO] BUILD FAILURE
> > >> [INFO] 
> > >> 
> > >> [INFO] Total time: 3.720 s
> > >> [INFO] Finished at: 2018-06-06T11:48:16+02:00
> > >> [INFO] 
> > >> 
> > >> [ERROR] Failed to execute goal on project wiquery-jquery-ui: Could not
> > >> resolve dependencies for project org.wicketstuff.wiquery:
> > >> wiquery-jquery-ui:jar:8.0-SNAPSHOT: Failure to find
> > >> org.wicketstuff.wiquery:wiquery-core:jar:tests:8.0-SNAPSHOT in
> > >> https://oss.sonatype.org/content/repositories/snapshots was cached in
> > >> the local repository, resolution will not be reattempted until the
> update
> > >> interval of sonatype-nexus-snapshots has elapsed or updates are
> forced ->
> > >> [Help 1]
> > >> [ERROR]
> > >
> > > Did you change something about test-jar configuration? I do not see
> > > `test-jar` generation enabled in the POM file.
> > >
> > > On Wed, Jun 6, 2018 at 11:43 AM, Emond Papegaaij <
> > >
> > > emond.papega...@topicus.nl> wrote:
> > >> Hi Thomas,
> > >>
> > >> The easiest way is to just run 'mvn install' and depend on
> 8.0-SNAPSHOT.
> > >> I did
> > >> not do a release, as I cannot push to central. If you want to run your
> > >> tests
> > >> on some CI server, you probably have to push the artifacts to a local
> > >> repo
> > >> also.
> > >>
> > >> Best regards,
> > >> Emond
> > >>
> > >> On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
> > >> > Hi Emond,
> > >> >
> > >> > How can I test this? Did you do a milestone release or do I have to
> > >>
> > >> build
> > >>
> > >> > from source and push to my local artifact repo?
> > >> >
> > >> > Best,
> > >> >
> > >> > Thomas
> > >> >
> > >> > On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij <
> > >>
> > >> emond.papega...@topicus.nl>
> > >>
> > >> > wrote:
> > >> > > I've just pushed a massive upgrade of all components. Removed all
> > >> > > deprecated
> > >> > > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> > >> > > refactoring.
> > >> > > Please test the changes in your project. The tests pass and the
> demo
> > >>
> > >> runs
> > >>
> > >> > > fine, but my project only uses a limited set of the UI components.
> > >> > >
> > >> > > Best regards,
> > >> > > Emond
> > >> > >
> > >> > > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> > >> > > > I'm planning to upgrade jQuery UI to the latest version next

Re: Release WiQuery for Wicket 8

2018-06-06 Thread Thomas Heigl
The culprit is:

https://github.com/wicketstuff/wiquery/commit/0235691174ceeede22b588d2f67868b940d9be3a

On Wed, Jun 6, 2018 at 11:51 AM, Thomas Heigl  wrote:

> `mvn clean install` fails for me because no test-jar is built for the core
> module:
>
> [INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS [
>>  0.353 s]
>> [INFO] WiQuery Core Project ... SUCCESS [
>>  2.673 s]
>> [INFO] WiQuery jQuery UI Project .. FAILURE [
>>  0.023 s]
>> [INFO] WiQuery Demo Project 8.0-SNAPSHOT .. SKIPPED
>> [INFO] 
>> 
>> [INFO] BUILD FAILURE
>> [INFO] 
>> 
>> [INFO] Total time: 3.720 s
>> [INFO] Finished at: 2018-06-06T11:48:16+02:00
>> [INFO] 
>> 
>> [ERROR] Failed to execute goal on project wiquery-jquery-ui: Could not
>> resolve dependencies for project org.wicketstuff.wiquery:
>> wiquery-jquery-ui:jar:8.0-SNAPSHOT: Failure to find
>> org.wicketstuff.wiquery:wiquery-core:jar:tests:8.0-SNAPSHOT in
>> https://oss.sonatype.org/content/repositories/snapshots was cached in
>> the local repository, resolution will not be reattempted until the update
>> interval of sonatype-nexus-snapshots has elapsed or updates are forced ->
>> [Help 1]
>> [ERROR]
>
>
> Did you change something about test-jar configuration? I do not see
> `test-jar` generation enabled in the POM file.
>
> On Wed, Jun 6, 2018 at 11:43 AM, Emond Papegaaij <
> emond.papega...@topicus.nl> wrote:
>
>> Hi Thomas,
>>
>> The easiest way is to just run 'mvn install' and depend on 8.0-SNAPSHOT.
>> I did
>> not do a release, as I cannot push to central. If you want to run your
>> tests
>> on some CI server, you probably have to push the artifacts to a local
>> repo
>> also.
>>
>> Best regards,
>> Emond
>>
>> On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
>> > Hi Emond,
>> >
>> > How can I test this? Did you do a milestone release or do I have to
>> build
>> > from source and push to my local artifact repo?
>> >
>> > Best,
>> >
>> > Thomas
>> >
>> > On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij <
>> emond.papega...@topicus.nl>
>> > wrote:
>> > > I've just pushed a massive upgrade of all components. Removed all
>> > > deprecated
>> > > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
>> > > refactoring.
>> > > Please test the changes in your project. The tests pass and the demo
>> runs
>> > > fine, but my project only uses a limited set of the UI components.
>> > >
>> > > Best regards,
>> > > Emond
>> > >
>> > > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
>> > > > I'm planning to upgrade jQuery UI to the latest version next week.
>> We
>> > > > are
>> > > > currently migrating all our applications to wicket 8 and also
>> depend on
>> > > > wiquery quite a lot. It does however seem that jQuery UI is mostly
>> dead.
>> > > > The rest of the world probably switched to yet another fancy
>> JavaScript
>> > >
>> > > ui
>> > >
>> > > > library. At least the will make it easy to stay up to date with the
>> > >
>> > > latest
>> > >
>> > > > version :)
>> > > >
>> > > > I can't push a release to central, but perhaps Martin can do that
>> when
>> > >
>> > > I'm
>> > >
>> > > > done? For now you can use a snapshot build. It works, but the UI API
>> > >
>> > > might
>> > >
>> > > > change a bit before the 8.0 release.
>> > > >
>> > > > Best regards,
>> > > > Emond Papegaaij
>> > > >
>> > > > Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :
>> > > > > Hi Ernesto,
>> > > > >
>> > > > > I'm not sure how many people are still using it. But as I said, my
>> > >
>> > > project
>> > >
>> > > > > heavily depends on it.
>> > > > >
>> > > > > @papegaaij has resolved all the compi

Re: Release WiQuery for Wicket 8

2018-06-06 Thread Thomas Heigl
`mvn clean install` fails for me because no test-jar is built for the core
module:

[INFO] WiQuery Parent 8.0-SNAPSHOT  SUCCESS [
>  0.353 s]
> [INFO] WiQuery Core Project ... SUCCESS [
>  2.673 s]
> [INFO] WiQuery jQuery UI Project .. FAILURE [
>  0.023 s]
> [INFO] WiQuery Demo Project 8.0-SNAPSHOT .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 3.720 s
> [INFO] Finished at: 2018-06-06T11:48:16+02:00
> [INFO]
> 
> [ERROR] Failed to execute goal on project wiquery-jquery-ui: Could not
> resolve dependencies for project
> org.wicketstuff.wiquery:wiquery-jquery-ui:jar:8.0-SNAPSHOT: Failure to find
> org.wicketstuff.wiquery:wiquery-core:jar:tests:8.0-SNAPSHOT in
> https://oss.sonatype.org/content/repositories/snapshots was cached in the
> local repository, resolution will not be reattempted until the update
> interval of sonatype-nexus-snapshots has elapsed or updates are forced ->
> [Help 1]
> [ERROR]


Did you change something about test-jar configuration? I do not see
`test-jar` generation enabled in the POM file.

On Wed, Jun 6, 2018 at 11:43 AM, Emond Papegaaij  wrote:

> Hi Thomas,
>
> The easiest way is to just run 'mvn install' and depend on 8.0-SNAPSHOT. I
> did
> not do a release, as I cannot push to central. If you want to run your
> tests
> on some CI server, you probably have to push the artifacts to a local repo
> also.
>
> Best regards,
> Emond
>
> On woensdag 6 juni 2018 11:36:54 CEST Thomas Heigl wrote:
> > Hi Emond,
> >
> > How can I test this? Did you do a milestone release or do I have to build
> > from source and push to my local artifact repo?
> >
> > Best,
> >
> > Thomas
> >
> > On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij <
> emond.papega...@topicus.nl>
> > wrote:
> > > I've just pushed a massive upgrade of all components. Removed all
> > > deprecated
> > > parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> > > refactoring.
> > > Please test the changes in your project. The tests pass and the demo
> runs
> > > fine, but my project only uses a limited set of the UI components.
> > >
> > > Best regards,
> > > Emond
> > >
> > > On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> > > > I'm planning to upgrade jQuery UI to the latest version next week. We
> > > > are
> > > > currently migrating all our applications to wicket 8 and also depend
> on
> > > > wiquery quite a lot. It does however seem that jQuery UI is mostly
> dead.
> > > > The rest of the world probably switched to yet another fancy
> JavaScript
> > >
> > > ui
> > >
> > > > library. At least the will make it easy to stay up to date with the
> > >
> > > latest
> > >
> > > > version :)
> > > >
> > > > I can't push a release to central, but perhaps Martin can do that
> when
> > >
> > > I'm
> > >
> > > > done? For now you can use a snapshot build. It works, but the UI API
> > >
> > > might
> > >
> > > > change a bit before the 8.0 release.
> > > >
> > > > Best regards,
> > > > Emond Papegaaij
> > > >
> > > > Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :
> > > > > Hi Ernesto,
> > > > >
> > > > > I'm not sure how many people are still using it. But as I said, my
> > >
> > > project
> > >
> > > > > heavily depends on it.
> > > > >
> > > > > @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> > > > > https://github.com/wicketstuff/wiquery) and a simple release of
> 8.0.0
> > > > > would
> > > > > be enough for me.
> > > > >
> > > > > Best,
> > > > >
> > > > > Thomas
> > > > >
> > > > > On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> > > > >
> > > > > reier...@gmail.com> wrote:
> > > > > > Hi,
> > > > > >
> > > > > > I do not know who is actually using this project. I use to
> > >
> > > contribute 

Re: Release WiQuery for Wicket 8

2018-06-06 Thread Thomas Heigl
Hi Emond,

How can I test this? Did you do a milestone release or do I have to build
from source and push to my local artifact repo?

Best,

Thomas

On Tue, Jun 5, 2018 at 3:01 PM, Emond Papegaaij 
wrote:

> I've just pushed a massive upgrade of all components. Removed all
> deprecated
> parts, upgraded jQuery UI to 1.12.1 and did some more cleanup and
> refactoring.
> Please test the changes in your project. The tests pass and the demo runs
> fine, but my project only uses a limited set of the UI components.
>
> Best regards,
> Emond
>
> On zaterdag 2 juni 2018 10:31:31 CEST you wrote:
> > I'm planning to upgrade jQuery UI to the latest version next week. We are
> > currently migrating all our applications to wicket 8 and also depend on
> > wiquery quite a lot. It does however seem that jQuery UI is mostly dead.
> > The rest of the world probably switched to yet another fancy JavaScript
> ui
> > library. At least the will make it easy to stay up to date with the
> latest
> > version :)
> >
> > I can't push a release to central, but perhaps Martin can do that when
> I'm
> > done? For now you can use a snapshot build. It works, but the UI API
> might
> > change a bit before the 8.0 release.
> >
> > Best regards,
> > Emond Papegaaij
> >
> > Op vr 1 jun. 2018 17:36 schreef Thomas Heigl :
> > > Hi Ernesto,
> > >
> > > I'm not sure how many people are still using it. But as I said, my
> project
> > > heavily depends on it.
> > >
> > > @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> > > https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0
> > > would
> > > be enough for me.
> > >
> > > Best,
> > >
> > > Thomas
> > >
> > > On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> > >
> > > reier...@gmail.com> wrote:
> > > > Hi,
> > > >
> > > > I do not know who is actually using this project. I use to
> contribute to
> > >
> > > it
> > >
> > > > a few years ago. I haven't used it for ages..
> > > >
> > > > On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl 
> > >
> > > wrote:
> > > > > Hi,
> > > > >
> > > > > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> > > >
> > > > somebody
> > > >
> > > > > please cut a release of WiQuery compatible with the new version?
> > > > >
> > > > > Our application still heavily relies on WiQuery and we can't move
> to
> > > >
> > > > Wicket
> > > >
> > > > > 8 without it.
> > > > >
> > > > > Best,
> > > > >
> > > > > Thomas
> > > >
> > > > --
> > > > Regards - Ernesto Reinaldo Barreiro
>
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


Re: Release WiQuery for Wicket 8

2018-06-01 Thread Thomas Heigl
Great! Thanks Martin!

On Fri, Jun 1, 2018 at 5:44 PM, Martin Grigorov 
wrote:

> On Fri, Jun 1, 2018, 18:35 Thomas Heigl  wrote:
>
> > Hi Ernesto,
> >
> > I'm not sure how many people are still using it. But as I said, my
> project
> > heavily depends on it.
> >
> > @papegaaij has resolved all the compile errors against 8.0.0-M9 (
> > https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0
> > would
> > be enough for me.
> >
>
> I'll be able to do it Monday morning.
>
>
> > Best,
> >
> > Thomas
> >
> > On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
> > reier...@gmail.com> wrote:
> >
> > > Hi,
> > >
> > > I do not know who is actually using this project. I use to contribute
> to
> > it
> > > a few years ago. I haven't used it for ages..
> > >
> > > On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl 
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> > > somebody
> > > > please cut a release of WiQuery compatible with the new version?
> > > >
> > > > Our application still heavily relies on WiQuery and we can't move to
> > > Wicket
> > > > 8 without it.
> > > >
> > > > Best,
> > > >
> > > > Thomas
> > > >
> > >
> > >
> > >
> > > --
> > > Regards - Ernesto Reinaldo Barreiro
> > >
> >
>


Re: Release WiQuery for Wicket 8

2018-06-01 Thread Thomas Heigl
Hi Ernesto,

I'm not sure how many people are still using it. But as I said, my project
heavily depends on it.

@papegaaij has resolved all the compile errors against 8.0.0-M9 (
https://github.com/wicketstuff/wiquery) and a simple release of 8.0.0 would
be enough for me.

Best,

Thomas

On Fri, Jun 1, 2018 at 5:05 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> I do not know who is actually using this project. I use to contribute to it
> a few years ago. I haven't used it for ages..
>
> On Fri, Jun 1, 2018 at 3:39 PM, Thomas Heigl  wrote:
>
> > Hi,
> >
> > Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could
> somebody
> > please cut a release of WiQuery compatible with the new version?
> >
> > Our application still heavily relies on WiQuery and we can't move to
> Wicket
> > 8 without it.
> >
> > Best,
> >
> > Thomas
> >
>
>
>
> --
> Regards - Ernesto Reinaldo Barreiro
>


Release WiQuery for Wicket 8

2018-06-01 Thread Thomas Heigl
Hi,

Following the release of Wicket 8.0.0 and WicketStuff 8.0.0, could somebody
please cut a release of WiQuery compatible with the new version?

Our application still heavily relies on WiQuery and we can't move to Wicket
8 without it.

Best,

Thomas


Re: Issues upgrading to Wicket 8.0.0-M9

2018-02-19 Thread Thomas Heigl
Thanks a lot Sven!

Thomas

On Mon, Feb 19, 2018 at 12:42 PM, Sven Meier <s...@meiers.net> wrote:

> No need for a quickstart for 2)… I've found the culprit.
>
> Will be fixed immediately.
>
> Thanks
> Sven
>
> ⁣Gesendet mit Blue ​
>
> Am 19. Feb. 2018, 12:23, um 12:23, Sven Meier <s...@meiers.net> schrieb:
> >Hi,
> >
> >many thanks for following our milestones closely.
> >
> >Could you please provide a quickstart for 2)?
> >
> >Regarding 3): Alternative would be calling beforeRender() instead. I'm
> >not sure whether that will work for you though, without understanding
> >why you called that internal API at all.
> >
> >Best regards
> >Sven
> >
> >⁣Gesendet mit Blue ​
> >
> >Am 19. Feb. 2018, 11:22, um 11:22, Thomas Heigl <tho...@umschalt.com>
> >schrieb:
> >>Hi all,
> >>
> >>I upgraded my application from M8 to M9 yesterday and encountered 3
> >>issues:
> >>
> >>1. Current WiQuery version is not compatible with M9
> >>
> >>It still depends on WicketEventJQueryResourceReference. It would be
> >>great
> >>if someone could cut a milestone release for WiQuery as well, so I can
> >>do
> >>further testing with my application.
> >>
> >>2. Failing tests for components with AjaxLazyLoadPanel
> >>
> >>It seems that it is not possible anymore, to load an AjaxLazyLoadPanel
> >>during an Ajax request. I have a panel that is initially invisible and
> >>shown via an Ajax toggle link that contains a AjaxLazyLoadPanel. My
> >>test
> >>fails with:
> >>
> >>java.lang.IllegalStateException: Components can no  longer be added
> >>> at
> >>>
> >>org.apache.wicket.page.PartialPageUpdate.assertNotFrozen(
> PartialPageUpdate.java:854)
> >>> at
> >>>
> >>org.apache.wicket.page.PartialPageUpdate.assertComponentsNotFrozen(
> PartialPageUpdate.java:847)
> >>> at
> >>org.apache.wicket.page.PartialPageUpdate.add(PartialPageUpdate.java:444)
> >>> at
> >>>
> >>org.apache.wicket.ajax.AjaxRequestHandler.add(
> AjaxRequestHandler.java:263)
> >>> at
> >>>
> >>org.apache.wicket.ajax.AjaxRequestHandler.add(
> AjaxRequestHandler.java:239)
> >>> at
> >>>
> >>org.apache.wicket.extensions.ajax.markup.html.AjaxLazyLoadPanel.lambda$
> isLoaded$1(AjaxLazyLoadPanel.java:258)
> >>> at java.util.Optional.ifPresent(Optional.java:159)
> >>> at
> >>>
> >>org.apache.wicket.extensions.ajax.markup.html.
> AjaxLazyLoadPanel.isLoaded(AjaxLazyLoadPanel.java:258)
> >>> at
> >>>
> >>org.apache.wicket.extensions.ajax.markup.html.
> AjaxLazyLoadPanel.onConfigure(AjaxLazyLoadPanel.java:212)
> >>
> >>
> >>The toggle link sets the panel containing the lazy-load panel visible
> >>and
> >>adds it to the ajax target:
> >>
> >>public void onClick(AjaxRequestTarget target) {
> >>> component.setVisible(!component.isVisible());
> >>> target.add(component);
> >>> }
> >>
> >>
> >>3. Removed (internal) APIs
> >>
> >>I have a custom component for rendering an infinite-scrolling list
> >that
> >>uses two (internal) methods to update the underlying DataView:
> >>
> >>public void onClick(AjaxRequestTarget target) {
> >>> pageable.setItemsPerPage(pageable.getItemsPerPage() +
> >>> additionalItems);
> >>
> >>view.prepareForRender();
> >>> view.afterRender();
> >>
> >>}
> >>
> >>
> >>Both `prepareForRender` and `afterRender` are no longer accessible.
> >>Does
> >>anyone have a suggestion what I could call instead? I sadly do not
> >>remember
> >>why exactly we work against Wicket's default rendering in that case
> >but
> >>it
> >>looks like we want to do everything *except* the actual render.
> >>
> >>Best regards,
> >>
> >>Thomas
>


Issues upgrading to Wicket 8.0.0-M9

2018-02-19 Thread Thomas Heigl
Hi all,

I upgraded my application from M8 to M9 yesterday and encountered 3 issues:

1. Current WiQuery version is not compatible with M9

It still depends on WicketEventJQueryResourceReference. It would be great
if someone could cut a milestone release for WiQuery as well, so I can do
further testing with my application.

2. Failing tests for components with AjaxLazyLoadPanel

It seems that it is not possible anymore, to load an AjaxLazyLoadPanel
during an Ajax request. I have a panel that is initially invisible and
shown via an Ajax toggle link that contains a AjaxLazyLoadPanel. My test
fails with:

java.lang.IllegalStateException: Components can no  longer be added
> at
> org.apache.wicket.page.PartialPageUpdate.assertNotFrozen(PartialPageUpdate.java:854)
> at
> org.apache.wicket.page.PartialPageUpdate.assertComponentsNotFrozen(PartialPageUpdate.java:847)
> at org.apache.wicket.page.PartialPageUpdate.add(PartialPageUpdate.java:444)
> at
> org.apache.wicket.ajax.AjaxRequestHandler.add(AjaxRequestHandler.java:263)
> at
> org.apache.wicket.ajax.AjaxRequestHandler.add(AjaxRequestHandler.java:239)
> at
> org.apache.wicket.extensions.ajax.markup.html.AjaxLazyLoadPanel.lambda$isLoaded$1(AjaxLazyLoadPanel.java:258)
> at java.util.Optional.ifPresent(Optional.java:159)
> at
> org.apache.wicket.extensions.ajax.markup.html.AjaxLazyLoadPanel.isLoaded(AjaxLazyLoadPanel.java:258)
> at
> org.apache.wicket.extensions.ajax.markup.html.AjaxLazyLoadPanel.onConfigure(AjaxLazyLoadPanel.java:212)


The toggle link sets the panel containing the lazy-load panel visible and
adds it to the ajax target:

public void onClick(AjaxRequestTarget target) {
> component.setVisible(!component.isVisible());
> target.add(component);
> }


3. Removed (internal) APIs

I have a custom component for rendering an infinite-scrolling list that
uses two (internal) methods to update the underlying DataView:

public void onClick(AjaxRequestTarget target) {
> pageable.setItemsPerPage(pageable.getItemsPerPage() +
> additionalItems);

view.prepareForRender();
> view.afterRender();

}


Both `prepareForRender` and `afterRender` are no longer accessible. Does
anyone have a suggestion what I could call instead? I sadly do not remember
why exactly we work against Wicket's default rendering in that case but it
looks like we want to do everything *except* the actual render.

Best regards,

Thomas


Re: Re-create bookmarkable pages on Ajax calls

2017-01-12 Thread Thomas Heigl
Alternatively, if this does not make any sense or is not possible at all,
would it be an option to approach this from the opposite direction, i.e.
make the pages really stateless, but still store them in the application
level cache so they don't have to be fully re-created for every Ajax call?

On Thu, Jan 12, 2017 at 6:48 PM, Thomas Heigl <tho...@umschalt.com> wrote:

> Hi Martin,
>
> Yes, I tried that, but what happens is this:
>
> When a user clicks on the an an Ajax link on a page that is not in the
> application cache, the whole page gets refreshed and nothing else happens.
> This is due to the following code in ListenerInterfaceRequestHandler:
>
> if (!canCallListenerInterfaceAfterExpiry && freshPage &&
>> (pageComponentProvider.getPageId() != null || component == null))
>> {
>> // A listener interface is invoked on an expired page.
>> // If the page is stateful then we cannot assume that the listener
>> interface is
>> // invoked on its initial state (right after page initialization) and
>> that its
>> // component and/or behavior will be available. That's why the
>> listener interface
>> // should be ignored and the best we can do is to re-paint the newly
>> constructed
>> // page.
>> if (isAjax)
>> {
>> policy = RedirectPolicy.ALWAYS_REDIRECT;
>> }
>> requestCycle.scheduleRequestHandlerAfterCurrent(new
>> RenderPageRequestHandler(
>> pageProvider, policy));
>> return;
>> }
>
>
> What I would like to do is mark some of my pages as "semi-stateless" (i.e.
> all state can be inferred from the URL), use fixed markup IDs for
> components with Ajax listeners, and let the listener be invoked anyway. I
> know that this is not the way Wicket is meant to be used, but it would
> allow me to massively reduce the memory footprint and simplify session
> distribution. My sessions are only around 1.5kb without the PageMap.
>
> I'd like to give this a try, but Page.isPageStateless() is final and I do
> not see a way to hook into this.
>
> Do you have any suggestions?
>
> Best regards,
>
> Thomas
>
> On Thu, Jan 12, 2017 at 12:43 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
>> Hi,
>>
>> You can setup a no-op IPageStore.
>> This way there won't be a call to ISerializer#serialize(Object) at all.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Thu, Jan 12, 2017 at 11:53 AM, Thomas Heigl <tho...@umschalt.com>
>> wrote:
>>
>> > I forgot to add:
>> >
>> > We are using the HTML5 History API to push state to the (bookmarkable)
>> URL,
>> > so a page can be re-created with *all* state from the URL alone.
>> >
>> > Thomas
>> >
>> > On Thu, Jan 12, 2017 at 11:47 AM, Thomas Heigl <tho...@umschalt.com>
>> > wrote:
>> >
>> > > Hi all,
>> > >
>> > > I'm looking for a solution to avoid serialization of bookmarkable
>> pages.
>> > >
>> > > These are yesterday's metrics from an instrumented version of
>> > Fast2WicketSerializer:
>> > >
>> > > "WicketSerializer.deserialize" : {
>> > >>   "count" : 4084,
>> > >>   "max" : 0.0308421623,
>> > >>   "mean" : 0.005861568417930906,
>> > >>   "min" : 0.00144874502,
>> > >>   "mean_rate" : 0.01926885221303454,
>> > >>   "duration_units" : "seconds",
>> > >>   "rate_units" : "calls/second"
>> > >> },
>> > >> "WicketSerializer.serialize" : {
>> > >>   "count" : 498884,
>> > >>   "max" : 0.007742393,
>> > >>   "mean" : 0.002135383760700826,
>> > >>   "min" : 8.2115001E-4,
>> > >>   "mean_rate" : 2.3538006959615907,
>> > >>   "duration_units" : "seconds",
>> > >>   "rate_units" : "calls/second"
>> > >> }
>> > >
>> > >
>> > > As you can see, Wicket serialized about 500.000 pages, but only 4000
>> > were ever
>> > > de-serialized. The deserialization is caused by users who use multiple
>> > tabs and
>> > > then trigger an ajax action on one of them.
>> > >
>> > > All my pages are unversioned, bookmarkable and mounted in a way that
>> > strips
>> > > version parameters from the URL.
>> > >
>> > > What I would like to do is completely disable HttpSessionDataStore,
>> rely
>> > only
>> > > on the application level cache that (from looking at the metrics is
>> > sufficient
>> > > in the vast majority of cases) and recreate the bookmarkable page for
>> the
>> > > remaining cases instead of de-serializing a stored version.
>> > >
>> > > I know this is possible with stateless pages, but my application is
>> very
>> > large
>> > > and converting it all to stateless would require a massive effort.
>> > >
>> > > Is there a way to implement this with Wicket 7.6?
>> > >
>> > > I'm aware of the flags "setRecreateBookmarkablePagesAfterExpiry" and
>> "
>> > setCallListenerInterfaceAfterExpiry"
>> > > but I'm not sure they apply to bookmarkable pages and Ajax calls.
>> > >
>> > > Any ideas would be greatly appreciated!
>> > >
>> > >
>> > > Best regards,
>> > >
>> > > Thomas
>> > >
>> > >
>> >
>>
>
>


Re: Re-create bookmarkable pages on Ajax calls

2017-01-12 Thread Thomas Heigl
Hi Martin,

Yes, I tried that, but what happens is this:

When a user clicks on the an an Ajax link on a page that is not in the
application cache, the whole page gets refreshed and nothing else happens.
This is due to the following code in ListenerInterfaceRequestHandler:

if (!canCallListenerInterfaceAfterExpiry && freshPage &&
> (pageComponentProvider.getPageId() != null || component == null))
> {
> // A listener interface is invoked on an expired page.
> // If the page is stateful then we cannot assume that the listener
> interface is
> // invoked on its initial state (right after page initialization) and
> that its
> // component and/or behavior will be available. That's why the
> listener interface
> // should be ignored and the best we can do is to re-paint the newly
> constructed
> // page.
> if (isAjax)
> {
> policy = RedirectPolicy.ALWAYS_REDIRECT;
> }
> requestCycle.scheduleRequestHandlerAfterCurrent(new
> RenderPageRequestHandler(
> pageProvider, policy));
> return;
> }


What I would like to do is mark some of my pages as "semi-stateless" (i.e.
all state can be inferred from the URL), use fixed markup IDs for
components with Ajax listeners, and let the listener be invoked anyway. I
know that this is not the way Wicket is meant to be used, but it would
allow me to massively reduce the memory footprint and simplify session
distribution. My sessions are only around 1.5kb without the PageMap.

I'd like to give this a try, but Page.isPageStateless() is final and I do
not see a way to hook into this.

Do you have any suggestions?

Best regards,

Thomas

On Thu, Jan 12, 2017 at 12:43 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> You can setup a no-op IPageStore.
> This way there won't be a call to ISerializer#serialize(Object) at all.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Thu, Jan 12, 2017 at 11:53 AM, Thomas Heigl <tho...@umschalt.com>
> wrote:
>
> > I forgot to add:
> >
> > We are using the HTML5 History API to push state to the (bookmarkable)
> URL,
> > so a page can be re-created with *all* state from the URL alone.
> >
> > Thomas
> >
> > On Thu, Jan 12, 2017 at 11:47 AM, Thomas Heigl <tho...@umschalt.com>
> > wrote:
> >
> > > Hi all,
> > >
> > > I'm looking for a solution to avoid serialization of bookmarkable
> pages.
> > >
> > > These are yesterday's metrics from an instrumented version of
> > Fast2WicketSerializer:
> > >
> > > "WicketSerializer.deserialize" : {
> > >>   "count" : 4084,
> > >>   "max" : 0.0308421623,
> > >>   "mean" : 0.005861568417930906,
> > >>   "min" : 0.00144874502,
> > >>   "mean_rate" : 0.01926885221303454,
> > >>   "duration_units" : "seconds",
> > >>   "rate_units" : "calls/second"
> > >> },
> > >> "WicketSerializer.serialize" : {
> > >>   "count" : 498884,
> > >>   "max" : 0.007742393,
> > >>   "mean" : 0.002135383760700826,
> > >>   "min" : 8.2115001E-4,
> > >>   "mean_rate" : 2.3538006959615907,
> > >>   "duration_units" : "seconds",
> > >>   "rate_units" : "calls/second"
> > >> }
> > >
> > >
> > > As you can see, Wicket serialized about 500.000 pages, but only 4000
> > were ever
> > > de-serialized. The deserialization is caused by users who use multiple
> > tabs and
> > > then trigger an ajax action on one of them.
> > >
> > > All my pages are unversioned, bookmarkable and mounted in a way that
> > strips
> > > version parameters from the URL.
> > >
> > > What I would like to do is completely disable HttpSessionDataStore,
> rely
> > only
> > > on the application level cache that (from looking at the metrics is
> > sufficient
> > > in the vast majority of cases) and recreate the bookmarkable page for
> the
> > > remaining cases instead of de-serializing a stored version.
> > >
> > > I know this is possible with stateless pages, but my application is
> very
> > large
> > > and converting it all to stateless would require a massive effort.
> > >
> > > Is there a way to implement this with Wicket 7.6?
> > >
> > > I'm aware of the flags "setRecreateBookmarkablePagesAfterExpiry" and "
> > setCallListenerInterfaceAfterExpiry"
> > > but I'm not sure they apply to bookmarkable pages and Ajax calls.
> > >
> > > Any ideas would be greatly appreciated!
> > >
> > >
> > > Best regards,
> > >
> > > Thomas
> > >
> > >
> >
>


Re: Re-create bookmarkable pages on Ajax calls

2017-01-12 Thread Thomas Heigl
I forgot to add:

We are using the HTML5 History API to push state to the (bookmarkable) URL,
so a page can be re-created with *all* state from the URL alone.

Thomas

On Thu, Jan 12, 2017 at 11:47 AM, Thomas Heigl <tho...@umschalt.com> wrote:

> Hi all,
>
> I'm looking for a solution to avoid serialization of bookmarkable pages.
>
> These are yesterday's metrics from an instrumented version of 
> Fast2WicketSerializer:
>
> "WicketSerializer.deserialize" : {
>>   "count" : 4084,
>>   "max" : 0.0308421623,
>>   "mean" : 0.005861568417930906,
>>   "min" : 0.00144874502,
>>   "mean_rate" : 0.01926885221303454,
>>   "duration_units" : "seconds",
>>   "rate_units" : "calls/second"
>> },
>> "WicketSerializer.serialize" : {
>>   "count" : 498884,
>>   "max" : 0.007742393,
>>   "mean" : 0.002135383760700826,
>>   "min" : 8.2115001E-4,
>>   "mean_rate" : 2.3538006959615907,
>>   "duration_units" : "seconds",
>>   "rate_units" : "calls/second"
>> }
>
>
> As you can see, Wicket serialized about 500.000 pages, but only 4000 were ever
> de-serialized. The deserialization is caused by users who use multiple tabs 
> and
> then trigger an ajax action on one of them.
>
> All my pages are unversioned, bookmarkable and mounted in a way that strips
> version parameters from the URL.
>
> What I would like to do is completely disable HttpSessionDataStore, rely only
> on the application level cache that (from looking at the metrics is sufficient
> in the vast majority of cases) and recreate the bookmarkable page for the
> remaining cases instead of de-serializing a stored version.
>
> I know this is possible with stateless pages, but my application is very large
> and converting it all to stateless would require a massive effort.
>
> Is there a way to implement this with Wicket 7.6?
>
> I'm aware of the flags "setRecreateBookmarkablePagesAfterExpiry" and 
> "setCallListenerInterfaceAfterExpiry"
> but I'm not sure they apply to bookmarkable pages and Ajax calls.
>
> Any ideas would be greatly appreciated!
>
>
> Best regards,
>
> Thomas
>
>


Re-create bookmarkable pages on Ajax calls

2017-01-12 Thread Thomas Heigl
Hi all,

I'm looking for a solution to avoid serialization of bookmarkable pages.

These are yesterday's metrics from an instrumented version of
Fast2WicketSerializer:

"WicketSerializer.deserialize" : {
>   "count" : 4084,
>   "max" : 0.0308421623,
>   "mean" : 0.005861568417930906,
>   "min" : 0.00144874502,
>   "mean_rate" : 0.01926885221303454,
>   "duration_units" : "seconds",
>   "rate_units" : "calls/second"
> },
> "WicketSerializer.serialize" : {
>   "count" : 498884,
>   "max" : 0.007742393,
>   "mean" : 0.002135383760700826,
>   "min" : 8.2115001E-4,
>   "mean_rate" : 2.3538006959615907,
>   "duration_units" : "seconds",
>   "rate_units" : "calls/second"
> }


As you can see, Wicket serialized about 500.000 pages, but only 4000 were ever
de-serialized. The deserialization is caused by users who use multiple tabs and
then trigger an ajax action on one of them.

All my pages are unversioned, bookmarkable and mounted in a way that strips
version parameters from the URL.

What I would like to do is completely disable HttpSessionDataStore, rely only
on the application level cache that (from looking at the metrics is sufficient
in the vast majority of cases) and recreate the bookmarkable page for the
remaining cases instead of de-serializing a stored version.

I know this is possible with stateless pages, but my application is very large
and converting it all to stateless would require a massive effort.

Is there a way to implement this with Wicket 7.6?

I'm aware of the flags "setRecreateBookmarkablePagesAfterExpiry" and
"setCallListenerInterfaceAfterExpiry"
but I'm not sure they apply to bookmarkable pages and Ajax calls.

Any ideas would be greatly appreciated!


Best regards,

Thomas


Re: Issues when upgrading to Wicket 7.2.0

2016-03-28 Thread Thomas Heigl
Hi Martin,

A quick follow-up:

2. Performance degradation of Wicket tests

I just profiled my Wicket tests with Yourkit against 6.21.0 and against
7.2.0. The biggest difference seems to be in
MarkupContainer.add(Component[]). It takes 10 times longer on 7.20 than on
6.21.0

It might be related to the issue you mentioned as most of my tests are
tests of individual components and panels that are relatively small. Is
there something we can do about this? Maybe use a strategy for component
adding so that we can switch to the old behavior for tests?

Two other methods take up considerable time compared to 6.21.0:

- MarkupContainer.getAssociatedMarkup() (5x more)
- MarkupContainer.newDequeueContext() (Does not exist in 6.21. and eats up
nearly as much time as MarkupContainer.add)

I can PM you my profiling results if you are interested.

3. serializer-fast2 throws NullPointerExceptions

You were right about the FST version. I only had it pinned in my
 but no in my . The version used until
6.21.0 (FST 2.10) seems to be the only version that does not throw NPEs in
my case. I'll use 2.10 for now and raise the issue with FST.

Best regards,

Thomas

On Mon, Mar 28, 2016 at 2:26 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Mon, Mar 28, 2016 at 2:17 PM, Thomas Heigl <tho...@umschalt.com> wrote:
>
> > Hi all,
> >
> > I just finished upgrading a larger application from Wicket 6.21.0 to
> Wicket
> > 7.2.0. I encountered 3 issues that more or less prevent me from pushing
> it
> > into production:
> >
> > 1. There seems to be an issue with  whose children
> are
> > added during onConfigure and stateless checking.
> >
> > Stateless checking triggers visibility checks on the enclosure too early,
> > i.e. before the enclosure's children have been added to the page,
> resulting
> > in exceptions like this:
> >
> > org.apache.wicket.WicketRuntimeException: Could not find child with id:
> > > emptyInfoPanel in the wicket:enclosure
> >
>
> I believe this is fixed in 7.3.0-SNAPSHOT.
> Please try it!
>
>
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:297)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.getChildComponent(Enclosure.java:275)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.getChild(Enclosure.java:138)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.java:173)
> > > at org.apache.wicket.Component.determineVisibility(Component.java:4400)
> > > at
> org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2152)
> > > at org.apache.wicket.Component.isStateless(Component.java:2069)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:83)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:66)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
> > > at
> > >
> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:981)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker.onBeforeRender(StatelessChecker.java:120)
> >
> >
> > For now, I adjusted my code to add the enclosed components during
> > onInitialize.
> >
> > 2. Performance degradation of Wicket tests
> >
> > All other things left equal, my 1500 Wicket tests take nearly a minute
> > longer to run compared to Wicket 6.21.0. I have not yet had time to
> profile
> > this. Have there been any configuration changes in WicketTester that
> might
> > have caused this?
> >
>
> I am not aware of such.
> There were some changes in the way Wicket traverses the children of a
> container (https://issues.apache.org/jira/browse/WICKET-5983) but it is
> slower only for very small pages (less than 10 components in the tree) and
> the diff is very small. I am not sure whether this is related.
> Wicket 7.x added support for component queueing and this might be the
> reason for this case.
>
>
> >
> > 3. serializer-fast2 throws NullPointerExceptions
> >
> > I first encountered this issue when upgrading to Wicket 7.2.0 but later
> > discovered that I have the same issue

Re: Issues when upgrading to Wicket 7.2.0

2016-03-28 Thread Thomas Heigl
Hi Martin,

Thanks for the ultra fast reply!

I believe this is fixed in 7.3.0-SNAPSHOT.
> Please try it!


I'll give it a try ASAP.

I am not aware of such.
> There were some changes in the way Wicket traverses the children of a
> container (https://issues.apache.org/jira/browse/WICKET-5983) but it is
> slower only for very small pages (less than 10 components in the tree) and
> the diff is very small. I am not sure whether this is related.
> Wicket 7.x added support for component queueing and this might be the
> reason for this case.


I'll do some profiling and report back to you.

I think we bumped the version of FST recently in wicketstuff-fast2. Could
> that be the reason ?
> The NPE is in FST code so I'd try to upgrade to latest version and if it
> still fails then report it to FST maintainer.


I'm pretty sure this is not related to FST. I have pinned the version of
FST to 2.45 in my POM. It works perfectly with 6.21.0, but throws the NPE
with 6.22.0:


> org.wicketstuff
> wicketstuff-serializer-fast2
> 6.21.0
> 
> 
> de.ruedigermoeller
> fst
> 2.45
> 


I checked
https://github.com/wicketstuff/core/compare/wicketstuff-core-6.21.0...wicketstuff-core-6.22.0
but there isn't anything related to serializer-fast except for the FST
dependency upgrade. I'll do some more investigating.

Best regards,

Thomas

On Mon, Mar 28, 2016 at 2:26 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Mon, Mar 28, 2016 at 2:17 PM, Thomas Heigl <tho...@umschalt.com> wrote:
>
> > Hi all,
> >
> > I just finished upgrading a larger application from Wicket 6.21.0 to
> Wicket
> > 7.2.0. I encountered 3 issues that more or less prevent me from pushing
> it
> > into production:
> >
> > 1. There seems to be an issue with  whose children
> are
> > added during onConfigure and stateless checking.
> >
> > Stateless checking triggers visibility checks on the enclosure too early,
> > i.e. before the enclosure's children have been added to the page,
> resulting
> > in exceptions like this:
> >
> > org.apache.wicket.WicketRuntimeException: Could not find child with id:
> > > emptyInfoPanel in the wicket:enclosure
> >
>
> I believe this is fixed in 7.3.0-SNAPSHOT.
> Please try it!
>
>
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:297)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.getChildComponent(Enclosure.java:275)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.getChild(Enclosure.java:138)
> > > at
> > >
> >
> org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.java:173)
> > > at org.apache.wicket.Component.determineVisibility(Component.java:4400)
> > > at
> org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2152)
> > > at org.apache.wicket.Component.isStateless(Component.java:2069)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:83)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:66)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
> > > at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
> > > at
> > >
> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:981)
> > > at
> > >
> >
> org.apache.wicket.devutils.stateless.StatelessChecker.onBeforeRender(StatelessChecker.java:120)
> >
> >
> > For now, I adjusted my code to add the enclosed components during
> > onInitialize.
> >
> > 2. Performance degradation of Wicket tests
> >
> > All other things left equal, my 1500 Wicket tests take nearly a minute
> > longer to run compared to Wicket 6.21.0. I have not yet had time to
> profile
> > this. Have there been any configuration changes in WicketTester that
> might
> > have caused this?
> >
>
> I am not aware of such.
> There were some changes in the way Wicket traverses the children of a
> container (https://issues.apache.org/jira/browse/WICKET-5983) but it is
> slower only for very small pages (less than 10 components in the tree) and
> the diff is very small. I am not sure whether this is related.
> Wicket 7.x added support for component queueing and this might be the
> reason for thi

Issues when upgrading to Wicket 7.2.0

2016-03-28 Thread Thomas Heigl
Hi all,

I just finished upgrading a larger application from Wicket 6.21.0 to Wicket
7.2.0. I encountered 3 issues that more or less prevent me from pushing it
into production:

1. There seems to be an issue with  whose children are
added during onConfigure and stateless checking.

Stateless checking triggers visibility checks on the enclosure too early,
i.e. before the enclosure's children have been added to the page, resulting
in exceptions like this:

org.apache.wicket.WicketRuntimeException: Could not find child with id:
> emptyInfoPanel in the wicket:enclosure
> at
> org.apache.wicket.markup.html.internal.Enclosure.checkChildComponent(Enclosure.java:297)
> at
> org.apache.wicket.markup.html.internal.Enclosure.getChildComponent(Enclosure.java:275)
> at
> org.apache.wicket.markup.html.internal.Enclosure.getChild(Enclosure.java:138)
> at
> org.apache.wicket.markup.html.internal.Enclosure.isVisible(Enclosure.java:173)
> at org.apache.wicket.Component.determineVisibility(Component.java:4400)
> at org.apache.wicket.Component.isVisibleInHierarchy(Component.java:2152)
> at org.apache.wicket.Component.isStateless(Component.java:2069)
> at
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:83)
> at
> org.apache.wicket.devutils.stateless.StatelessChecker$1.component(StatelessChecker.java:66)
> at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:144)
> at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:162)
> at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:123)
> at org.apache.wicket.util.visit.Visits.visitChildren(Visits.java:192)
> at
> org.apache.wicket.MarkupContainer.visitChildren(MarkupContainer.java:981)
> at
> org.apache.wicket.devutils.stateless.StatelessChecker.onBeforeRender(StatelessChecker.java:120)


For now, I adjusted my code to add the enclosed components during
onInitialize.

2. Performance degradation of Wicket tests

All other things left equal, my 1500 Wicket tests take nearly a minute
longer to run compared to Wicket 6.21.0. I have not yet had time to profile
this. Have there been any configuration changes in WicketTester that might
have caused this?

3. serializer-fast2 throws NullPointerExceptions

I first encountered this issue when upgrading to Wicket 7.2.0 but later
discovered that I have the same issue when moving from Wicketstuff 6.21.0
to 6.22.0, so I guess this issue was introduced somehow between those minor
versions. It has nothing to do with the dependency version of
de.ruedigermoeller.fst, as I have fixed that to the latest version in my
POM.


> Caused by: java.lang.NullPointerException: null
> at
> org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:375)
> at
> org.nustaq.serialization.FSTObjectOutput.writeObjectWithContext(FSTObjectOutput.java:361)
> at
> org.nustaq.serialization.FSTObjectOutput.writeObjectFields(FSTObjectOutput.java:639)


I tried to check the history between those two versions on Github but
couldn't find any differences. For now, I solved this issue by pinning my
version of wicketstuff-serializer-fast2 to 6.21.0.

I can try to provide quickstarts for #1 and #3 if needed, altough it might
be difficult to extract the behavior from my application. My most pressing
issue is #2 as it is the only one I cannot work around and I'm very
sensitive to build and test feedback time.

Any help would be greatly appreciated.

Best regards,

Thomas


String length validation and windows line breaks

2014-07-12 Thread Thomas Heigl
Hey all,

Recenty, probably after moving to Wicket 6.16, we see some strange behavior
for TextAreas.

We have been using a JavaScript library to limit the number of characters a
user can enter in a textbox for years. Now we started getting validation
exceptions on the server that the user entered a too many characters. It
turned out that Wicket counts Windows '\r\n' as two characters, while JS
counts them as one.

We can easily fix that with a custom StringConverter that replaces Windows
linebreaks, but I was wondering if there were some recent changes in Wicket
that could have triggered these issues?

Cheers,

Thomas


Re: How to handle click on removed links - WicketRuntimeException (Component 'xxx' has been removed from page)?

2014-07-09 Thread Thomas Heigl
+1

We're also seeing these sporadically and a custom exception would help a
lot.

Thomas
On Jul 7, 2014 10:12 AM, Martin Grigorov mgrigo...@apache.org wrote:

 Please create a ticket!
 With a patch with the custom exception will make its processing even
 faster!
 Thank you!

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Mon, Jul 7, 2014 at 11:08 AM, Daniel Stoch daniel.st...@gmail.com
 wrote:

  I think the simplest solution for now (until we invent a better one)
  is to define a dedicated exception class for such case (similar to
  ListenerInvocationNotAllowedException which is raised if user tries
  click on disabled links). Then we can catch such exception and handle
  it eg. as described by Martin in my previous post (How to handle
  click on disabled links - ListenerInvocationNotAllowedException?).
 
  --
  Daniel
 
  On Fri, Jul 4, 2014 at 5:38 PM, Ernesto Reinaldo Barreiro
  reier...@gmail.com wrote:
   maybe what is needed is a fail silently ajax request ;-)
  
  
   On Fri, Jul 4, 2014 at 5:36 PM, Ernesto Reinaldo Barreiro 
   reier...@gmail.com wrote:
  
   Hi,
  
  
   On Fri, Jul 4, 2014 at 4:59 PM, Daniel Stoch daniel.st...@gmail.com
   wrote:
  
   Sorry, but for me all these solutions are hacks :).
  
  
   Why? As far as they are under control... Isn't software development
   production controlled hacks? Wicket itself is a hack and so do are
   other WEB frameworks like GWT. As far as you remain in control I do
 not
  see
   the problem. All frameworks have limitations... Why not get the best
 of
   them and circumvent those.
  
  
   I want to use standard components (eg. AjaxLink) to do simple things.
   I don't want to think everywhere how to handle such scenarios. It
   should be handled properly on a framework level. I think there is
   always possibility that component state on server and DOM tree on
   client browser are inconsistent (and not necessary because of push
   requests). Maybe it should be a dedicated exception on such situation
   (Component 'xxx' has been removed from page.) at least or maybe we
   can invent a better solution in core?
  
  
   I do agree that would be optimal.
  
  
  
  
   --
   Daniel
  
   On Fri, Jul 4, 2014 at 4:11 PM, Ernesto Reinaldo Barreiro
   reier...@gmail.com wrote:
Maybe you could even just push JSON to client side and generate
 items
content at client side which is going to be way faster
   
   
On Fri, Jul 4, 2014 at 4:06 PM, Ernesto Reinaldo Barreiro 
reier...@gmail.com wrote:
   
Why don't you try routing all the click to a part of you
 application
   that
is always available? E.g.
   
1- You have a list of items that are pushed... They are in a
 certain
container that is always there... At client and server side
2- The items are pushed but instead of normal AJAX link you use
  link to
the parent never changing container passing ID of item. This way
  click
   will
never fail and it is still sort of object oriented...
   
   
   
On Fri, Jul 4, 2014 at 3:59 PM, Daniel Stoch 
  daniel.st...@gmail.com
wrote:
   
On Fri, Jul 4, 2014 at 3:14 PM, Martin Grigorov 
  mgrigo...@apache.org
   
wrote:
 Hi,

 You can use Atmopshere to hide/disable the client side too, not
   just the
 server side.
   
Of course, I already do that.
But user can click the link after state was changed on the server
  side
but before these changes are pushed to client browser.
   
--
Daniel
   
   

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov


 On Fri, Jul 4, 2014 at 1:46 PM, Daniel Stoch 
   daniel.st...@gmail.com
wrote:

 On Fri, Jul 4, 2014 at 12:33 PM, Sven Meier s...@meiers.net
   wrote:
  So page was rendered in a browser,
  on the server component tree was changed
 
 
  What triggers the change to the component tree? On which
  thread?
   Are
you
  using websockets?
 
  Sven

 In general this thread is not initialized by user action but
 by
 application. So yes, it can be push from a server (eg. using
 Atmosphere - this is my case) or by ajax self updating
 behavior.

 --
 DS

 
 
 
  On 07/04/2014 12:13 PM, Daniel Stoch wrote:
 
  Hi all,
 
  I think such question occurs from time to time on this
 list,
   but I
  have never found a good answer how to solve such problem in
   general.
  The problem is similar to my last question:
 
 

   
  
 
 http://apache-wicket.1842946.n4.nabble.com/How-to-handle-click-on-disabled-links-ListenerInvocationNotAllowedException-td4666287.html
  but now there is a situation when link was removed from
 page
   (not
  disabled).
 
  So page was rendered in a browser, on the server component
  tree
   was
  changed, but user clicks a link in a browser before this
  changes

NPEs when locating resources after upgrading to Wicket 6.13.0

2014-01-13 Thread Thomas Heigl
Hey all,

I just tried to upgrade to Wicket 6.13.0 because of the new JQuery version
packaged with it. It breaks some of our resource mounting functionality
that has been working since 1.4x and some package resources cannot be found
anymore. Have there been changes to resource mounting in this release?

A sample exception looks like this:

org.apache.wicket.WicketRuntimeException: An error occurred while
 generating an Url for handler
 'ResourceReferenceRequestHandler{resourceReference=scope:
 com.synexit.friendsic.view.wicket.staticcontent.StaticContentBase; name:
 /images/alt_neu_v2.jpg; locale: null; style: null; variation: null,
 pageParameters=}'
 at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
 at
 org.apache.wicket.util.resource.ResourceStreamWrapper.init(ResourceStreamWrapper.java:36)
 at
 org.apache.wicket.request.resource.PackageResource$ProcessingResourceStream.init(PackageResource.java:476)
 at
 org.apache.wicket.request.resource.PackageResource$ProcessingResourceStream.init(PackageResource.java:472)
 at
 org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:465)
 at
 org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395)
 at
 org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:227)
 at
 org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81)
 at
 org.apache.wicket.request.resource.caching.FilenameWithVersionResourceCachingStrategy.decorateUrl(FilenameWithVersionResourceCachingStrategy.java:102)
 at
 org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.mapHandler(BasicResourceReferenceMapper.java:238)
 at
 org.apache.wicket.request.mapper.ParentPathReferenceRewriter.mapHandler(ParentPathReferenceRewriter.java:91)
 at
 org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:215)
 at
 org.apache.wicket.util.tester.BaseWicketTester$TestRequestMapper.mapHandler(BaseWicketTester.java:2758)
 at
 org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:429)
 at
 org.apache.wicket.request.cycle.RequestCycle.urlFor(RequestCycle.java:529)
 at
 org.apache.wicket.request.cycle.RequestCycle.urlFor(RequestCycle.java:492)


The resource is there and works perfectly with Wicket 6.12.0.

Any ideas?

Cheers,

Thomas


Re: NPEs when locating resources after upgrading to Wicket 6.13.0

2014-01-13 Thread Thomas Heigl
Hey Martin,

I don't have time to create a quickstart at the moment. If you can't find
the problem without it I'll try to do it in the next days.

The resource is definitely there and downgrading to 6.12.0 fixes the
problem immediately.

Thomas


On Mon, Jan 13, 2014 at 2:15 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Please put a breakpoint at

 https://github.com/apache/wicket/blob/wicket-6.x/wicket-core/src/main/java/org/apache/wicket/request/resource/PackageResource.java?source=cc#L431

 It seems  /images/alt_neu_v2.jpg; locale: null; style: null; variation:
 null does not exists. Only in this case the resource stream would be null.

 Unfortunately this happens in a private method and I don't see how to
 workaround it.
 Please create a ticket with a quickstart.

 Martin Grigorov
 Wicket Training and Consulting


 On Mon, Jan 13, 2014 at 3:10 PM, Martin Grigorov mgrigo...@apache.org
 wrote:

  Hi,
 
  Please check your logs for : Argument 'delegate' may not be null.
 
  This is what
  g.Args.notNull(Args.java:41)
   at
   org.apache.wicket.util.resource.ResourceStreamWrapper.init(
  ResourceStreamWrapper.java:36)
   at
 
  should actually throw.
 
  I am looking why it could be null.
 
  Martin Grigorov
  Wicket Training and Consulting
 
 
  On Mon, Jan 13, 2014 at 3:02 PM, Thomas Heigl tho...@umschalt.com
 wrote:
 
  Hey all,
 
  I just tried to upgrade to Wicket 6.13.0 because of the new JQuery
 version
  packaged with it. It breaks some of our resource mounting functionality
  that has been working since 1.4x and some package resources cannot be
  found
  anymore. Have there been changes to resource mounting in this release?
 
  A sample exception looks like this:
 
  org.apache.wicket.WicketRuntimeException: An error occurred while
   generating an Url for handler
   'ResourceReferenceRequestHandler{resourceReference=scope:
   com.synexit.friendsic.view.wicket.staticcontent.StaticContentBase;
 name:
   /images/alt_neu_v2.jpg; locale: null; style: null; variation: null,
   pageParameters=}'
   at org.apache.wicket.util.lang.Args.notNull(Args.java:41)
   at
  
 
 org.apache.wicket.util.resource.ResourceStreamWrapper.init(ResourceStreamWrapper.java:36)
   at
  
 
 org.apache.wicket.request.resource.PackageResource$ProcessingResourceStream.init(PackageResource.java:476)
   at
  
 
 org.apache.wicket.request.resource.PackageResource$ProcessingResourceStream.init(PackageResource.java:472)
   at
  
 
 org.apache.wicket.request.resource.PackageResource.internalGetResourceStream(PackageResource.java:465)
   at
  
 
 org.apache.wicket.request.resource.PackageResource.getCacheableResourceStream(PackageResource.java:395)
   at
  
 
 org.apache.wicket.request.resource.PackageResource.getCacheKey(PackageResource.java:227)
   at
  
 
 org.apache.wicket.request.resource.caching.version.RequestCycleCachedResourceVersion.getVersion(RequestCycleCachedResourceVersion.java:81)
   at
  
 
 org.apache.wicket.request.resource.caching.FilenameWithVersionResourceCachingStrategy.decorateUrl(FilenameWithVersionResourceCachingStrategy.java:102)
   at
  
 
 org.apache.wicket.core.request.mapper.BasicResourceReferenceMapper.mapHandler(BasicResourceReferenceMapper.java:238)
   at
  
 
 org.apache.wicket.request.mapper.ParentPathReferenceRewriter.mapHandler(ParentPathReferenceRewriter.java:91)
   at
  
 
 org.apache.wicket.request.mapper.CompoundRequestMapper.mapHandler(CompoundRequestMapper.java:215)
   at
  
 
 org.apache.wicket.util.tester.BaseWicketTester$TestRequestMapper.mapHandler(BaseWicketTester.java:2758)
   at
  
 
 org.apache.wicket.request.cycle.RequestCycle.mapUrlFor(RequestCycle.java:429)
   at
  
 
 org.apache.wicket.request.cycle.RequestCycle.urlFor(RequestCycle.java:529)
   at
  
 
 org.apache.wicket.request.cycle.RequestCycle.urlFor(RequestCycle.java:492)
 
 
  The resource is there and works perfectly with Wicket 6.12.0.
 
  Any ideas?
 
  Cheers,
 
  Thomas
 
 
 



Ajax file upload broken in IE8 with Wicket 6.9.0

2013-07-23 Thread Thomas Heigl
Hey all,

After upgrading to Wicket 6.9.0 our ajax file upload started stalling and
on some machines even crashing IE8. Downgrading to 6.8.0 immediately fixed
the problem.

I verified that the issue is not related to the new jQuery version by
downgrading to Wicket 6.8.0 but setting the jQuery resource reference to
1.10.1. File upload still works in that case.

I browsed the history of wicket-ajax-jquery.js since 6.8.0 but didn't find
anything too suspicious.

Does anyone have any idea what could cause the problem or is experiencing
the same issues?

I can try to create some kind of quickstart if that helps.

Cheers,

Thomas


Re: Ajax file upload broken in IE8 with Wicket 6.9.0

2013-07-23 Thread Thomas Heigl
Hey Martin,

The example works fine.

I just tried to narrow the problem down and found that the root cause is
using AjaxFormSubmitBehavior(onchange) on the input field. The absolute
minimal example that crashes my IE8/XP on the first or second upload is:

public class TestPage extends WebPage {
 public TestPage(PageParameters pp) {
 super(pp);
 final FormVoid f = new FormVoid(form);
 f.setMultiPart(true);
 add(f);
 final FileUploadField uploadField = new FileUploadField(fileInput, new
 ListModelFileUpload());
 uploadField.add(new AjaxFormSubmitBehavior(onchange) {});
 f.add(uploadField);
 }
 }


html xmlns=http://www.w3.org/1999/xhtml; xmlns:wicket=
 http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
 body
 form wicket:id=form
 input type=file wicket:id=fileInput /
 /form
 /body
 /html


Hope that helps to track the problem down.

Thomas




On Tue, Jul 23, 2013 at 1:42 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Just tested wicket-examples 6.0-SNAPSHOT - Ajax - File Upload Example and
 it works OK on Windows XP / IE 8.
 I'll upload 6.9.1 to
 http://www.wicket-library.com/wicket-examples-6.0.x/ajax/upload?1 so you
 can test there


 On Tue, Jul 23, 2013 at 2:30 PM, Thomas Heigl tho...@umschalt.com wrote:

  Hey all,
 
  After upgrading to Wicket 6.9.0 our ajax file upload started stalling and
  on some machines even crashing IE8. Downgrading to 6.8.0 immediately
 fixed
  the problem.
 
  I verified that the issue is not related to the new jQuery version by
  downgrading to Wicket 6.8.0 but setting the jQuery resource reference to
  1.10.1. File upload still works in that case.
 
  I browsed the history of wicket-ajax-jquery.js since 6.8.0 but didn't
 find
  anything too suspicious.
 
  Does anyone have any idea what could cause the problem or is experiencing
  the same issues?
 
  I can try to create some kind of quickstart if that helps.
 
  Cheers,
 
  Thomas
 



Re: Ajax file upload broken in IE8 with Wicket 6.9.0

2013-07-23 Thread Thomas Heigl

 Please pack this code in a quickstart and attach it to a ticket.


I'll do that.

What do you mean by crash exactly ? Does the process end with segfault or
 what ?


IE has 99% CPU usage and does not respond anymore.


On Tue, Jul 23, 2013 at 3:10 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Please pack this code in a quickstart and attach it to a ticket.
 What do you mean by crash exactly ? Does the process end with segfault or
 what ?


 On Tue, Jul 23, 2013 at 4:08 PM, Thomas Heigl tho...@umschalt.com wrote:

  Hey Martin,
 
  The example works fine.
 
  I just tried to narrow the problem down and found that the root cause is
  using AjaxFormSubmitBehavior(onchange) on the input field. The absolute
  minimal example that crashes my IE8/XP on the first or second upload is:
 
  public class TestPage extends WebPage {
   public TestPage(PageParameters pp) {
   super(pp);
   final FormVoid f = new FormVoid(form);
   f.setMultiPart(true);
   add(f);
   final FileUploadField uploadField = new FileUploadField(fileInput,
 new
   ListModelFileUpload());
   uploadField.add(new AjaxFormSubmitBehavior(onchange) {});
   f.add(uploadField);
   }
   }
 
 
  html xmlns=http://www.w3.org/1999/xhtml; xmlns:wicket=
   http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
   body
   form wicket:id=form
   input type=file wicket:id=fileInput /
   /form
   /body
   /html
 
 
  Hope that helps to track the problem down.
 
  Thomas
 
 
 
 
  On Tue, Jul 23, 2013 at 1:42 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi,
  
   Just tested wicket-examples 6.0-SNAPSHOT - Ajax - File Upload Example
  and
   it works OK on Windows XP / IE 8.
   I'll upload 6.9.1 to
   http://www.wicket-library.com/wicket-examples-6.0.x/ajax/upload?1 so
 you
   can test there
  
  
   On Tue, Jul 23, 2013 at 2:30 PM, Thomas Heigl tho...@umschalt.com
  wrote:
  
Hey all,
   
After upgrading to Wicket 6.9.0 our ajax file upload started stalling
  and
on some machines even crashing IE8. Downgrading to 6.8.0 immediately
   fixed
the problem.
   
I verified that the issue is not related to the new jQuery version by
downgrading to Wicket 6.8.0 but setting the jQuery resource reference
  to
1.10.1. File upload still works in that case.
   
I browsed the history of wicket-ajax-jquery.js since 6.8.0 but didn't
   find
anything too suspicious.
   
Does anyone have any idea what could cause the problem or is
  experiencing
the same issues?
   
I can try to create some kind of quickstart if that helps.
   
Cheers,
   
Thomas
   
  
 



Re: Ajax file upload broken in IE8 with Wicket 6.9.0

2013-07-23 Thread Thomas Heigl
See https://issues.apache.org/jira/browse/WICKET-5283


On Tue, Jul 23, 2013 at 3:12 PM, Thomas Heigl tho...@umschalt.com wrote:

 Please pack this code in a quickstart and attach it to a ticket.


 I'll do that.

 What do you mean by crash exactly ? Does the process end with segfault or
 what ?


 IE has 99% CPU usage and does not respond anymore.


 On Tue, Jul 23, 2013 at 3:10 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Please pack this code in a quickstart and attach it to a ticket.
 What do you mean by crash exactly ? Does the process end with segfault
 or
 what ?


 On Tue, Jul 23, 2013 at 4:08 PM, Thomas Heigl tho...@umschalt.com
 wrote:

  Hey Martin,
 
  The example works fine.
 
  I just tried to narrow the problem down and found that the root cause is
  using AjaxFormSubmitBehavior(onchange) on the input field. The
 absolute
  minimal example that crashes my IE8/XP on the first or second upload is:
 
  public class TestPage extends WebPage {
   public TestPage(PageParameters pp) {
   super(pp);
   final FormVoid f = new FormVoid(form);
   f.setMultiPart(true);
   add(f);
   final FileUploadField uploadField = new FileUploadField(fileInput,
 new
   ListModelFileUpload());
   uploadField.add(new AjaxFormSubmitBehavior(onchange) {});
   f.add(uploadField);
   }
   }
 
 
  html xmlns=http://www.w3.org/1999/xhtml; xmlns:wicket=
   http://wicket.apache.org/dtds.data/wicket-xhtml1.4-strict.dtd;
   body
   form wicket:id=form
   input type=file wicket:id=fileInput /
   /form
   /body
   /html
 
 
  Hope that helps to track the problem down.
 
  Thomas
 
 
 
 
  On Tue, Jul 23, 2013 at 1:42 PM, Martin Grigorov mgrigo...@apache.org
  wrote:
 
   Hi,
  
   Just tested wicket-examples 6.0-SNAPSHOT - Ajax - File Upload
 Example
  and
   it works OK on Windows XP / IE 8.
   I'll upload 6.9.1 to
   http://www.wicket-library.com/wicket-examples-6.0.x/ajax/upload?1 so
 you
   can test there
  
  
   On Tue, Jul 23, 2013 at 2:30 PM, Thomas Heigl tho...@umschalt.com
  wrote:
  
Hey all,
   
After upgrading to Wicket 6.9.0 our ajax file upload started
 stalling
  and
on some machines even crashing IE8. Downgrading to 6.8.0 immediately
   fixed
the problem.
   
I verified that the issue is not related to the new jQuery version
 by
downgrading to Wicket 6.8.0 but setting the jQuery resource
 reference
  to
1.10.1. File upload still works in that case.
   
I browsed the history of wicket-ajax-jquery.js since 6.8.0 but
 didn't
   find
anything too suspicious.
   
Does anyone have any idea what could cause the problem or is
  experiencing
the same issues?
   
I can try to create some kind of quickstart if that helps.
   
Cheers,
   
Thomas
   
  
 





Re: Server side caching of generated resources

2013-06-18 Thread Thomas Heigl
Hey Michael,

Yeah respond.js is exactly what we are using. However, I overlooked that it
kind of supports CDN/X-Domain via a local proxy. The solution looks a bit
complicated but I'll give it a try now. If it works it would solve my
original issue.

Cheers,

Thomas


On Tue, Jun 18, 2013 at 10:11 AM, Michael Haitz michael.ha...@1und1.dewrote:

 Hi,

 if you describe your process a bit more, i could help you out. In one of
 my projects we render additional/browser specific css files like all
 other css files (except the browser checks based on ClientProperties, no
 conditional comments and so on).

 Do you know https://github.com/scottjehl/Respond?

 best,
 Michael

 Am 17.06.2013 um 17:30 schrieb Thomas Heigl tho...@umschalt.com:

  Hey Michael,
 
  but isn't it enough to send the correct cache headers + a calculated
  filename that contains the hash of file?
 
 
  I actually have aggressive caching and a CDN in front of my resources. So
  in 90% of cases, a resource is only generated once per deployment. My
  problem is that I need to fetch some resources directly from my origin to
  support media queries for IE=8 and avoid running into cross-domain
 issues.
  So between 5 and 10% of users directly hit my origin for CSS resources
 and
  the load generated by this is getting too high.
 
  Thanks a lot for your suggestions. I'll try to think of a solution that
  does not involve Wicket.
 
  Cheers,
 
  Thomas
 
 
 
  On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz michael.ha...@1und1.de
 wrote:
 
  Hi,
 
  but isn't it enough to send the correct cache headers + a calculated
  filename that contains the hash of file?
  I think caching on your container isn't the best option (using nginx or
  varnish or a CDN like Akamai or something similar is way better), else
  you've to compile each resource on all your containers and you need some
  heap space for the content.
 
  best,
  Michael
 
  Am 17.06.2013 um 16:02 schrieb Michael Haitz michael.ha...@1und1.de
  :
 
  Hi Thomas,
 
  it depends on your deployment mode:
 
  if (application.usesDevelopmentConfig())
  {
   // development mode:
   // use last-modified timestamp of packaged resource for resource
  caching
   // cache the version information for the lifetime of the current
  http request
   resourceVersion = new RequestCycleCachedResourceVersion(
   new LastModifiedResourceVersion());
  }
  else
  {
   // deployment mode:
   // use message digest over resource content for resource caching
   // cache the version information for the lifetime of the
  application
   resourceVersion = new CachingResourceVersion(new
  MessageDigestResourceVersion());
  }
 
  best,
  Michael
 
 
  Am 17.06.2013 um 15:21 schrieb Thomas Heigl tho...@umschalt.com:
 
  Hi all,
 
  I was wondering if Wicket has a built-in mechanism for caching the
  generated byte[] of package resources. I use concatenated resource
  bundles
  that are compressed using the YUI CSS/JS compressors.
 
  Using the default settings, compression is performed for every request
  that
  does not have it in the client cache. Since this compression is a very
  complex operation I'd like to perform it only once.
 
  Cheers,
 
  Thomas
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Server side caching of generated resources

2013-06-17 Thread Thomas Heigl
Hi all,

I was wondering if Wicket has a built-in mechanism for caching the
generated byte[] of package resources. I use concatenated resource bundles
that are compressed using the YUI CSS/JS compressors.

Using the default settings, compression is performed for every request that
does not have it in the client cache. Since this compression is a very
complex operation I'd like to perform it only once.

Cheers,

Thomas


Re: Server side caching of generated resources

2013-06-17 Thread Thomas Heigl
Hi Michael,

This caches only the resource version, e.g. message digest, but not the
actual contents of the resouce.

Kind regards,

Thomas


On Mon, Jun 17, 2013 at 4:02 PM, Michael Haitz michael.ha...@1und1.dewrote:

 Hi Thomas,

 it depends on your deployment mode:

  if (application.usesDevelopmentConfig())
 {
 // development mode:
 // use last-modified timestamp of packaged resource for resource
 caching
 // cache the version information for the lifetime of the current
 http request
 resourceVersion = new RequestCycleCachedResourceVersion(
 new LastModifiedResourceVersion());
 }
 else
 {
 // deployment mode:
 // use message digest over resource content for resource caching
 // cache the version information for the lifetime of the
 application
 resourceVersion = new CachingResourceVersion(new
 MessageDigestResourceVersion());
 }

 best,
 Michael


 Am 17.06.2013 um 15:21 schrieb Thomas Heigl tho...@umschalt.com:

  Hi all,
 
  I was wondering if Wicket has a built-in mechanism for caching the
  generated byte[] of package resources. I use concatenated resource
 bundles
  that are compressed using the YUI CSS/JS compressors.
 
  Using the default settings, compression is performed for every request
 that
  does not have it in the client cache. Since this compression is a very
  complex operation I'd like to perform it only once.
 
  Cheers,
 
  Thomas


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Server side caching of generated resources

2013-06-17 Thread Thomas Heigl
Hey Michael,

but isn't it enough to send the correct cache headers + a calculated
 filename that contains the hash of file?


I actually have aggressive caching and a CDN in front of my resources. So
in 90% of cases, a resource is only generated once per deployment. My
problem is that I need to fetch some resources directly from my origin to
support media queries for IE=8 and avoid running into cross-domain issues.
So between 5 and 10% of users directly hit my origin for CSS resources and
the load generated by this is getting too high.

Thanks a lot for your suggestions. I'll try to think of a solution that
does not involve Wicket.

Cheers,

Thomas



On Mon, Jun 17, 2013 at 4:57 PM, Michael Haitz michael.ha...@1und1.dewrote:

 Hi,

 but isn't it enough to send the correct cache headers + a calculated
 filename that contains the hash of file?
 I think caching on your container isn't the best option (using nginx or
 varnish or a CDN like Akamai or something similar is way better), else
 you've to compile each resource on all your containers and you need some
 heap space for the content.

 best,
 Michael

 Am 17.06.2013 um 16:02 schrieb Michael Haitz michael.ha...@1und1.de
 :

  Hi Thomas,
 
  it depends on your deployment mode:
 
  if (application.usesDevelopmentConfig())
  {
// development mode:
// use last-modified timestamp of packaged resource for resource
 caching
// cache the version information for the lifetime of the current
 http request
resourceVersion = new RequestCycleCachedResourceVersion(
new LastModifiedResourceVersion());
  }
  else
  {
// deployment mode:
// use message digest over resource content for resource caching
// cache the version information for the lifetime of the
 application
resourceVersion = new CachingResourceVersion(new
 MessageDigestResourceVersion());
  }
 
  best,
  Michael
 
 
  Am 17.06.2013 um 15:21 schrieb Thomas Heigl tho...@umschalt.com:
 
  Hi all,
 
  I was wondering if Wicket has a built-in mechanism for caching the
  generated byte[] of package resources. I use concatenated resource
 bundles
  that are compressed using the YUI CSS/JS compressors.
 
  Using the default settings, compression is performed for every request
 that
  does not have it in the client cache. Since this compression is a very
  complex operation I'd like to perform it only once.
 
  Cheers,
 
  Thomas
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 


 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




OOM in Tests with Wicket 6.7.0

2013-04-19 Thread Thomas Heigl
Hey Guys,

Yesterday I upgraded our 6.6.0 app to 6.7.0 and my CI build broke
immediately with OOM (Heap Space) exceptions while running our
integration/smoke test suite. The suite renders all pages in the
application using WicketTester and uses the full Spring application context.

I tried increasing the Maven memory settings, but even doubling them to
1.5g did not fix the issue. Downgrading to 6.6.0 fixed the problem.

Have there been any changes to WicketTester that could cause such a memory
leak? I can try profiling memory usage next week if necessary.

Cheers,

Thomas


Re: Integrating Wicket with an Angular app

2013-02-27 Thread Thomas Heigl
Hey Guys,

Thanks a lot for sharing your ideas. Maybe together we can find a smooth
way to integrate the two ;)

My plan for now is to create an abstract wicket page for angular apps that
renders basic HTML structure including menus, footers, meta tags etc. This
page also adds the basic angular JS dependency. Concrete pages can then add
JS/CSS dependencies for an angular app included via Webjars and bind the
application to a tag within the wicket page.

I'll keep you updated when I have know how this works out.

Cheers,

Thomas

On Tue, Feb 26, 2013 at 11:16 AM, sauli.ketola sauli.ket...@mbnet.fiwrote:

 Ernesto Reinaldo Barreiro-4 wrote
  I want this special page to be be stateless, so I'm planning to serve
 JSON
   needed via mounted resources.

 I've been also playing with a similar idea. Nice to hear that there are
 similar attempts going on. In my case I decided to serve the JSON through a
 Spring Controller
 http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/
 http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/  . I feel
 this makes the service interface more straightforward to implement -
 compared to mounted resources.

 The motivation for me to do this is that I get to package the angular
 application like a standard java web application, and it can then be
 deployed to a servlet container like the other applications. If needed, I
 also get a session for the application (I can for example check that the
 service calls are made in a session + get hold of the user information,
 etc).

 Also I have found that none of the javascript frameworks that I have
 studied
 so far have decent support for i18n - with this I could use Wicket for
 that.
 Wicket has also other features that are useful for this like javascript and
 css resource serving. (I haven't done this yet but) I think I could add the
 required js resources in all of my panels and wicket handles them so that
 the javascripts are included in the resulting page only once.

 I will try to get a sample application made to demonstrate this.



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/Integrating-Wicket-with-an-Angular-app-tp4656794p4656820.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Integrating Wicket with an Angular app

2013-02-27 Thread Thomas Heigl

 What will you include on this Webjar? Only angular your your code as well?
 Isn't this approach a bit slow for development?


The Angular app is managed by Grunt.js http://gruntjs.com/. Build, Code
Quality, Resource Aggregation, Tests, Dev Server, Live Reloading ..
everything is run via Grunt and we use a pure JS-way of developing this
application. The idea is that we treat the app like any other dependency of
the Wicket application, develop it separately, release it separately and
import it as a maven dependency.

The Webjar will contain the merged JS and CSS files as well as images and
all other resources needed by the application.
Wicket-Webjarshttp://www.webjars.org/documentation#wicket should
then mount everything under something like /webjars/my_angular_app/.

I think this is actually the fastest way to to develop such an application
because it is completely decoupled from my Java/Wicket stack. At least
that's my theory ;)

Thomas

On Wed, Feb 27, 2013 at 11:35 AM, Ernesto Reinaldo Barreiro 
reier...@gmail.com wrote:

 Hi Thomas,

 We just posted at the same time:-)

 On Wed, Feb 27, 2013 at 11:19 AM, Thomas Heigl tho...@umschalt.com
 wrote:

  Hey Guys,
 
  Thanks a lot for sharing your ideas. Maybe together we can find a smooth
  way to integrate the two ;)
 

 Please see my previous e-mail. I will gladly join forces with anyone
 willing to help/contribute angular based components.


 
  My plan for now is to create an abstract wicket page for angular apps
 that
  renders basic HTML structure including menus, footers, meta tags etc.
 This
  page also adds the basic angular JS dependency. Concrete pages can then
 add
  JS/CSS dependencies for an angular app included via Webjars and bind the
  application to a tag within the wicket page.
 

 What will you include on this Webjar? Only angular your your code as well?
 Isn't this approach a bit slow for development?


 
  I'll keep you updated when I have know how this works out.
 
  Please do so.

 Cheers,


  On Tue, Feb 26, 2013 at 11:16 AM, sauli.ketola sauli.ket...@mbnet.fi
  wrote:
 
   Ernesto Reinaldo Barreiro-4 wrote
I want this special page to be be stateless, so I'm planning to serve
   JSON
 needed via mounted resources.
  
   I've been also playing with a similar idea. Nice to hear that there are
   similar attempts going on. In my case I decided to serve the JSON
  through a
   Spring Controller
   http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/
   http://blog.springsource.org/2009/03/08/rest-in-spring-3-mvc/  . I
  feel
   this makes the service interface more straightforward to implement -
   compared to mounted resources.
  
   The motivation for me to do this is that I get to package the angular
   application like a standard java web application, and it can then be
   deployed to a servlet container like the other applications. If
 needed, I
   also get a session for the application (I can for example check that
 the
   service calls are made in a session + get hold of the user information,
   etc).
  
   Also I have found that none of the javascript frameworks that I have
   studied
   so far have decent support for i18n - with this I could use Wicket for
   that.
   Wicket has also other features that are useful for this like javascript
  and
   css resource serving. (I haven't done this yet but) I think I could add
  the
   required js resources in all of my panels and wicket handles them so
 that
   the javascripts are included in the resulting page only once.
  
   I will try to get a sample application made to demonstrate this.
  
  
  
   --
   View this message in context:
  
 
 http://apache-wicket.1842946.n4.nabble.com/Integrating-Wicket-with-an-Angular-app-tp4656794p4656820.html
   Sent from the Users forum mailing list archive at Nabble.com.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
 



 --
 Regards - Ernesto Reinaldo Barreiro
 Antilia Soft
 http://antiliasoft.com/ http://antiliasoft.com/antilia



Integrating Wicket with an Angular app

2013-02-25 Thread Thomas Heigl
Hey all,

I recently started a new project based on our existing Wicket
infrastructure. This infrastructure handles typical web application
requirements like registration, signup, authentication, user management
functionality and is very solid.

One of the main requirements of the new site we are building is a highly
dynamic, public search and browse interface similar to pinterest.com,
fab.com etc. In the past I've been bitten by trying to implement such
solutions in Wicket. Especially things like infinite scrolling, AJAX
animations, etc can be really hard to implement and have a lot of overhead
compared to pure JSON/REST solutions.

So this time I decided to create a hybrid application, half Wicket half
Angular.js where Wicket handles all of the stuff mentioned above but
delegates the content of some pages to a single page Angular application.
My plan is that wicket would still mount the page, provide authentication
and the basic frame of the page including menus, headers, and footers.

One of my biggest questions at the moment is how to pull the Angular
application, that has its own git repository, build, test etc into my
Wicket Application. Today I've setup a build that generates a
Webjarhttp://www.webjars.org/ that
I could import into my Wicket Application but I'm not 100% sure
that that's the best way to go.

Does anyone of you have any experience with such a setup? Any ideas,
suggestions, warnings?

Thanks a lot in advance!

Thomas


Re: AjaxCallListener precondition with user input

2012-11-26 Thread Thomas Heigl
Hey Sekib,

Thanks a lot for your input!

In case anybody has a similar problem, I ended up solving it through an
AjaxCallListener with a little workaround. If the user confirms the alert,
I re-trigger a click on the link with additional data and check for that in
my precondition. This can be used to perform arbitrary async actions in a
listener precondition.

@Override
 public CharSequence getPrecondition(final Component component) {

return if (attrs.event.extraData != 'OK')  { jConfirm(function(r)
 { if (r) { $('# + component.getMarkupId() + ').trigger('click', 'OK'); }
 }); return false;;

}


Cheers,

Thomas

On Mon, Nov 5, 2012 at 2:35 PM, Sekib_Omazic sekib1...@gmail.com wrote:

 If this is an option for you, you could use modal dialog from twitter
 bootstrap (short example can be fond here:
 https://github.com/sekib/twittermodal). I don't use public CharSequence
 getPrecondition(final Component component) at all. Modal dialog is shown
 after clicking the link (no ajax call). Only a click on Of course button
 triggers an ajax call.



 --
 View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/AjaxCallListener-precondition-with-user-input-tp4653566p4653622.html
 Sent from the Users forum mailing list archive at Nabble.com.

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Wicket 6.2: Required attribute on ListMultipleChoice has no effect

2012-11-06 Thread Thomas Heigl
Hey All,

I noticed that setRequired(true) on ListMultipleChoice does not have an
effect anymore after upgrading to Wicket 6 from Wicket 1.5.7.

I think it might be a problem with the ajax library because the AJAX post
request looks like this (where 'tags' is my select multiple / field)

tags:null
 :submit:1


The ListMultipleChoice now thinks that the input was non-empty (String
'null') and returns an empty list when converting the value and hence
passes the required check because an empty list is non-null.

@Override
protected CollectionT convertValue(String[] ids) throws
ConversionException
{
if (ids != null  ids.length  0  !Strings.isEmpty(ids[0]))
{
return convertChoiceIdsToChoices(ids);
}
else
{
ArrayListT result = new ArrayListT();
addRetainedDisabled(result);
return result;
}
}

When I change the component to a simple DropDownChoice the request looks
like this and everything works as expected:


 tags:
 :submit:1


Cheers,

Thomas


AjaxCallListener precondition with user input

2012-11-02 Thread Thomas Heigl
Hey all,

I'm currently in the progress of migrating a largish Wicket 1.5 app to
Wicket 6.2. The only major problem I could not resolve so far are
precondition scripts with user input.

My old code looked like this:

   @Override
 public CharSequence postDecorateScript(Component component, CharSequence
 script) {
 return jConfirm(function(r) { if (r) { + script + }});;
 }


The whole script was decorated and the callback only executed if the user
pressed OK in a custom confirmation dialog.

In Wicket 6, there are no more script decorators, just listeners that
provide hooks into the ajax lifecycle, so I changed my code to this:


 @Override
 public CharSequence getPrecondition(final Component component) {
 return jConfirm(function(r) { if (r) { return true; } }); return false;;
 }


The problem is, that the callback function I'm passing to jConfirm is
evaluated only when the user makes a selection, but the precondition has to
return an output immediately. It would work if we used browser-level
confirmation dialogs, but we use a custom jquery dialog for better user
experience.

Is there any way to emulate the pre-Wicket 6 behavior using listeners?

Kind regards,

Thomas


Re: wicket 1.4 to 1.5 migration - page id in urls issue - how to remove for certain pages

2012-07-12 Thread Thomas Heigl
Hi Sam,

I wrote a custom MountedMapper for the project I'm currently working on.
All it does, is not rendering the page version info for pages. For all
other components it is still turned on. IMHO this mimics the pre-1.5
behavior. We've been using it in production for quite a while now and it
works fine:

public static class NoHybridMountedMapper extends MountedMapper {
 public NoHybridMountedMapper(String mountPath, Class? extends
 IRequestablePage pageClass) {
 super(mountPath, pageClass);
 }
 @Override
 protected void encodePageComponentInfo(Url url, PageComponentInfo info) {
 final boolean isComponentListener = info != null 
 info.getComponentInfo() != null;
 if (isComponentListener) {
 // only encode information about components, not pages
 super.encodePageComponentInfo(url, info);
 }
 }
 }


Hope this helps,

Cheers,

Thomas

On Thu, Jul 12, 2012 at 9:15 AM, Sam Zilverberg samzilverb...@gmail.comwrote:

 Thank you very much Jeremy!
 It was a good read through, very informative!
 I already browsed through Ivan's post but deemed it unrelevant to my
 problem on the first read.
 After reading the second post, then reading Ivan's post again, I now
 understand the page versioning system a lot better :)

 Sadly though now I'm not sure there is a solution to my problem and that I
 will have to cope with how the versioning/url works now.
 I'm looking for another way to encode the page version, possibly not into
 the url but using cookies/http headers/session/anything.
 I will search nabble/stackoverflow for this.
 If you already have links to posts dealing with this matter feel free to
 post them :)
 I will definitely post any links I find that are useful for anyone who
 encounters this post in the future.


 On Thu, Jul 12, 2012 at 2:43 AM, Jeremy Thomerson 
 jer...@wickettraining.com
  wrote:

  On Wed, Jul 11, 2012 at 6:41 PM, Jeremy Thomerson 
  jer...@wickettraining.com
   wrote:
 
  
   On Wed, Jul 11, 2012 at 2:54 PM, Sam Zilverberg 
 samzilverb...@gmail.com
  wrote:
  
   I have no problem that the page is being constructed everytime.
  
  
   Just one note here: the page is not being constructed every time.  Put
 a
   breakpoint or System.out.println in your constructor to verify this.
   There
   was a change in Wicket 1.5 that increases the page ID for each change
   rather than having the older ID and version number combination.
  
   See this post where Igor schooled me in the new stuff :)
   http://tinyurl.com/cmfrpj9
  
   --
   Jeremy Thomerson
   http://wickettraining.com
   *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
  
 
  And see this post for the more direct answer to your original question:
  http://tinyurl.com/cdl99xy
 
  --
  Jeremy Thomerson
  http://wickettraining.com
  *Need a CMS for Wicket?  Use Brix! http://brixcms.org*
 



Re: Wicket 1.5 and nested forms

2012-06-13 Thread Thomas Heigl
Hello,

In case anyone else is encountering this problem when migrating from 1.4 to
1.5, I solved it by overriding delegateSubmit in my form:

public static enum SubmitOrder {
 /** Submit form submitter before forms (1.5 Default) */
 OUTSIDE_IN,
 /** Submit form submitter after forms (1.4 Default) */
 INSIDE_OUT
 }

 private SubmitOrder submitOrder = SubmitOrder.OUTSIDE_IN;



@Override
 protected void delegateSubmit(IFormSubmitter submittingComponent) {
 switch (submitOrder) {
 case OUTSIDE_IN:
 super.delegateSubmit(submittingComponent);
 break;
 case INSIDE_OUT:
 super.delegateSubmit(null);
 if (submittingComponent != null) {
 submittingComponent.onSubmit();
 }
 break;
 }
 }


Cheers,

Thomas

On Wed, May 9, 2012 at 3:07 PM, Thomas Heigl tho...@umschalt.com wrote:

 Hey Martin,


 WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
 which says that this order is changed in 1.4.15


 I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
 with 1.4.20.

 This is the way how it works in 1.5/6.x. I'm not sure why it is not
 documented.
  But there are different opinions about it:
  https://issues.apache.org/jira/browse/WICKET-3705


 I just thought about it some more and I think the new behavior is quite
 counter intuitive. For instance my following usecase:

 final class CompoundForm extends BaseFormExample {
 public CompoundSearchRequestForm(String id, final IModelExample model) {
 super(id, model);
  add(new BaseForm(baseForm, model));
 add(new ConfigurationForm(configurationForm, model));
  add(new SettingsForm(settingsForm, model));
 add(new AjaxButton(save) {
  @Override
 protected void onSubmit(AjaxRequestTarget target, Form? form) {

  // do nothing - delegated to form's onSubmit
  }
 });
 }
 @Override
  protected void onSubmit() {
 super.onSubmit();
 listener.saveModel(getModelObject());
  }
 }


 I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
 behavior. This works, but the button is now pretty useless and just
 triggers a form submit. In the form's onSubmit on the other hand I don't
 have (direct) access to the AjaxRequestTarget so I'd have to split
 functionality into the two handlers and always think about which order they
 are called in.

 The problems get harder if you don't have complete control over the nested
 form structure. For instance, when you are using the Wizards from
 wicket-extensions. They always wrap their contents in a compound form. We
 use ajaxified versions of Wizards extensively and the new form submit flow
 makes them very hard to use. The next/finish/previous links of the wizard
 are now called before any of the actual forms inside the wizard had their
 onSubmit handler called. The buttons in fact *replace* the inner form
 before it has been submitted and I had to move the wizards state change
 logic to onConfigure to make it work again:

 @Override
 public void onActiveStepChanged(IWizardStep newStep) {
  // do nothing - logic moved to #onConfigure to prevent replacement of
 the form before validation of nested forms
 }
 @Override
 protected void onConfigure() {
  super.onConfigure();
 final IWizardStep activeStep = getActiveStep();
 getForm().replace(activeStep.getView(VIEW_ID, this, this));
  getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
 }


 I worked around these problems but I'd greatly prefer a way to configure
 the form submit order somewhere. Ideally on the compound form or the ajax
 button.

 Thomas

 On Wed, May 9, 2012 at 1:24 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi Thomas,
 
  On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com
 wrote:
  Hello,
 
  I notices a strange behavior after upgrading to Wicket 1.5. Nested
 forms
  are submitted in a different order.
 
  I have structures like this:
 
  - Compound Form
  -- Subform 1
  -- Subform 2
  -- Subform 3
  - Submit Link/Button for Compound Form
 
 
  In Wicket 1.4 the order of calls to onSubmit was like this:
 
  1. Subforms
  2. Compound Form
  3. Submit Link/Button
 
  In multiple locations I had logic in the subforms' onSubmit handlers
 that
  do cleanup, re-attaching of models to entities etc. before my links
 submit
  handler is called and persists my model object.
 
  In Wicket 1.5 the submit link's handler that I use for my main logic is
  actually called before the subforms:
 
  1. Submit Link
  2. Subforms
  3. Compound Form
 
  I can fix this by moving all my compound form logic from the
 link/buttons
  onSubmit handler to the compound form's handler, but wanted to check
 first
  if this behavior is intentional?
  Is this the way to do it in Wicket 1.5?
 
  This is the way how it works in 1.5/6.x. I'm not sure why it is not
 documented.
  But there are different opinions about it:
  https://issues.apache.org/jira/browse/WICKET-3705

 WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
 which says

Wicket 1.5.6 Relative URL rendering

2012-05-09 Thread Thomas Heigl
Hello,

Since Wicket 1.5.6, the UrlRender generates all URLs prefixed with ./
when using RequestCycle.get().urlFor(pageClass). The Problem is that for my
application's homepage the generated URL is ./. which does not really
make sense.

Is there any reason for doing this? What caused the change to relative URL
rendering?

Cheers,

Thomas


Re: Wicket 1.5.6 Relative URL rendering

2012-05-09 Thread Thomas Heigl
Hey Martin,

Thanks for the explanation!

How exactly the home page is broken ? Do you have custom RequestMapper
 for the home page ?


The problem is in absolute URL generation. I generate absolute URLs for
sitemaps, canonical URL tags etc and my logic broke after upgrading to
Wicket 1.5.6 because my URL absolutizer was confused by ./.  for the
homepage.

I don't use a request mapper for the homepage. Would it solve the problem
to mount the homepage under /?

Cheers,

Thomas

On Wed, May 9, 2012 at 11:00 AM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 They have always been relative.
 Before 1.5.6: some/relative/url
 After 1.5.6: ./somerelative/url

 Both are the same. The reason is
 https://issues.apache.org/jira/browse/WICKET-4260

 How exactly the home page is broken ? Do you have custom RequestMapper
 for the home page ?

 On Wed, May 9, 2012 at 11:56 AM, Thomas Heigl tho...@umschalt.com wrote:
  Hello,
 
  Since Wicket 1.5.6, the UrlRender generates all URLs prefixed with ./
  when using RequestCycle.get().urlFor(pageClass). The Problem is that for
 my
  application's homepage the generated URL is ./. which does not really
  make sense.
 
  Is there any reason for doing this? What caused the change to relative
 URL
  rendering?
 
  Cheers,
 
  Thomas



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: MarkupNotFoundException for Fragment and TransparentWebMarkupContainer

2012-05-09 Thread Thomas Heigl
I had the same problem. I solved it by using the transparent container as
markup provider for the fragment:

add(new MyFragment(fragmentId, getTransparentBodyContainer()))

It works, but is kind of awkward, as subclasses shouldn't really know about
transparent containers in the base class.

Thomas

On Wed, May 9, 2012 at 12:52 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Hi,

 Create a ticket with a quickstart please.
 As a workaround you can put the fragment in the base page's html.

 On Wed, May 9, 2012 at 1:18 PM, Dirk Forchel dirk.forc...@exedio.com
 wrote:
  Hello,
  I've a question regarding Fragements inside a
 TransparentWebMarkupContainer.
  I've a base WebPage with a TransparentWebMarkupContainer to allow
 subclasses
  register CSS classes on the body tag. If I add a Fragment to one of these
  subsclasses, the markup of the Fragment is not found.
 
  BasePage.java
 
  Markup of BasePage.html
 
  My subclass looks like:
 
  Markup of FragmentTestPage.html
 
 
  Why is it not possible to do this!? And why doesn't find the
  FragmentMarkupSourcingStrategy the markup for Fragment testFragment in
 the
  providong markup container (Page class FragmentTestPage)?
 
 
  --
  View this message in context:
 http://apache-wicket.1842946.n4.nabble.com/MarkupNotFoundException-for-Fragment-and-TransparentWebMarkupContainer-tp4619968.html
  Sent from the Users forum mailing list archive at Nabble.com.
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Wicket 1.5 and nested forms

2012-05-09 Thread Thomas Heigl
Hello,

I notices a strange behavior after upgrading to Wicket 1.5. Nested forms
are submitted in a different order.

I have structures like this:

- Compound Form
 -- Subform 1
 -- Subform 2
 -- Subform 3
 - Submit Link/Button for Compound Form


In Wicket 1.4 the order of calls to onSubmit was like this:

1. Subforms
2. Compound Form
3. Submit Link/Button

In multiple locations I had logic in the subforms' onSubmit handlers that
do cleanup, re-attaching of models to entities etc. before my links submit
handler is called and persists my model object.

In Wicket 1.5 the submit link's handler that I use for my main logic is
actually called before the subforms:

1. Submit Link
2. Subforms
3. Compound Form

I can fix this by moving all my compound form logic from the link/buttons
onSubmit handler to the compound form's handler, but wanted to check first
if this behavior is intentional?
Is this the way to do it in Wicket 1.5?

Cheers,

Thomas


Re: Wicket 1.5 and nested forms

2012-05-09 Thread Thomas Heigl
Hey Martin,


 WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
 which says that this order is changed in 1.4.15


I upgraded to Wicket 1.5 from Wicket 1.4.20 and it still has been working
with 1.4.20.

This is the way how it works in 1.5/6.x. I'm not sure why it is not
 documented.
  But there are different opinions about it:
  https://issues.apache.org/jira/browse/WICKET-3705


I just thought about it some more and I think the new behavior is quite
counter intuitive. For instance my following usecase:

final class CompoundForm extends BaseFormExample {
 public CompoundSearchRequestForm(String id, final IModelExample model) {
 super(id, model);
 add(new BaseForm(baseForm, model));
 add(new ConfigurationForm(configurationForm, model));
 add(new SettingsForm(settingsForm, model));
 add(new AjaxButton(save) {
 @Override
 protected void onSubmit(AjaxRequestTarget target, Form? form) {

// do nothing - delegated to form's onSubmit
 }
 });
 }
 @Override
 protected void onSubmit() {
 super.onSubmit();
 listener.saveModel(getModelObject());
 }
 }


I moved the buttons onSubmit logic to the form's logic to mimic Wicket 1.4
behavior. This works, but the button is now pretty useless and just
triggers a form submit. In the form's onSubmit on the other hand I don't
have (direct) access to the AjaxRequestTarget so I'd have to split
functionality into the two handlers and always think about which order they
are called in.

The problems get harder if you don't have complete control over the nested
form structure. For instance, when you are using the Wizards from
wicket-extensions. They always wrap their contents in a compound form. We
use ajaxified versions of Wizards extensively and the new form submit flow
makes them very hard to use. The next/finish/previous links of the wizard
are now called before any of the actual forms inside the wizard had their
onSubmit handler called. The buttons in fact *replace* the inner form
before it has been submitted and I had to move the wizards state change
logic to onConfigure to make it work again:

@Override
 public void onActiveStepChanged(IWizardStep newStep) {
 // do nothing - logic moved to #onConfigure to prevent replacement of the
 form before validation of nested forms
 }
 @Override
 protected void onConfigure() {
 super.onConfigure();
 final IWizardStep activeStep = getActiveStep();
 getForm().replace(activeStep.getView(VIEW_ID, this, this));
 getForm().replace(activeStep.getHeader(HEADER_ID, this, this));
 }


I worked around these problems but I'd greatly prefer a way to configure
the form submit order somewhere. Ideally on the compound form or the ajax
button.

Thomas

On Wed, May 9, 2012 at 1:24 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 On Wed, May 9, 2012 at 2:22 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  Hi Thomas,
 
  On Wed, May 9, 2012 at 2:12 PM, Thomas Heigl tho...@umschalt.com
 wrote:
  Hello,
 
  I notices a strange behavior after upgrading to Wicket 1.5. Nested forms
  are submitted in a different order.
 
  I have structures like this:
 
  - Compound Form
  -- Subform 1
  -- Subform 2
  -- Subform 3
  - Submit Link/Button for Compound Form
 
 
  In Wicket 1.4 the order of calls to onSubmit was like this:
 
  1. Subforms
  2. Compound Form
  3. Submit Link/Button
 
  In multiple locations I had logic in the subforms' onSubmit handlers
 that
  do cleanup, re-attaching of models to entities etc. before my links
 submit
  handler is called and persists my model object.
 
  In Wicket 1.5 the submit link's handler that I use for my main logic is
  actually called before the subforms:
 
  1. Submit Link
  2. Subforms
  3. Compound Form
 
  I can fix this by moving all my compound form logic from the
 link/buttons
  onSubmit handler to the compound form's handler, but wanted to check
 first
  if this behavior is intentional?
  Is this the way to do it in Wicket 1.5?
 
  This is the way how it works in 1.5/6.x. I'm not sure why it is not
 documented.
  But there are different opinions about it:
  https://issues.apache.org/jira/browse/WICKET-3705

 WICKET-3705 links to https://issues.apache.org/jira/browse/WICKET-1894
 which says that this order is changed in 1.4.15

 
 
  Cheers,
 
  Thomas
 
 
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




WICKET-1.5.6 Feedback messages not updated on stateless pages

2012-05-06 Thread Thomas Heigl
Hello,

I'm currently in the process of migrating a largish Wicket 1.4 application
to 1.5. When moving from 1.5.5 to 1.5.6 something related to feedback
messages breaks.

On all my stateless pages, feedback messages are not rendered anymore when
using:

@Override
protected void onError(AjaxRequestTarget target, Form? form) {
target.addChildren(MyForm.this, FeedbackPanel.class);
}

The form is correctly traversed, all FeedbackPanels are added to the ajax
target, and the ajax response actually contains the updated markup for the
feedback panel. Just the message itself is missing and Wicket shows the
typical Component-targeted feedback message has been left unrendered
message.

I checked the JIRA issues for 1.5.6 but didn't see anything related to
feedback messages. Has there been some intentional change or is something
broken in 1.5.6?

Cheers,

Thomas


Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread Thomas Heigl
Hey all,

I have a requirement where I'd like to create a Wicket Session outside of a
Wicket request:

My application runs stand-alone (no problem here) and as a Facebook
application. Facebook calls my REST authentication service with a user's
credentials if they open my application in facebook. At this point I don't
have a Wicket session, but want to signin the user in my
AuthenticatedWebSession from wicket-auth-roles. I'm using the
WicketSessionFilter in front of my REST service to get access to the
session, which works fine if the session already exists. If there is no
session, as in this case, the filter throws an IllegalArgumentException.

Since I have access to the Wicket Application I thought about calling
Application.get().newSession(), but this method only accepts Wicket's
WebRequest and WebResponse objects. Is it somehow possible to bind a new
session in a non-wicket request?

Kind regards,

Thomas


Re: Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread Thomas Heigl
Hey David,

Thanks for your reply! I have thought about using Spring Security or Shire,
but at the moment the minimal wicket-auth-roles is enough for my
requirements. I'd prefer to just create the session myself when I need it.

Any other ideas?

Cheers,

THomas

On Tue, Nov 15, 2011 at 8:02 PM, David Berkman david.berk...@glu.comwrote:

 Apache Shiro, and create a shiro version of WebSession. Then wicket can
 ask for the Shio Session from the Http context, and you can get it
 outside the context.

 David

 -Original Message-
 From: Thomas Heigl [mailto:tho...@umschalt.com]
 Sent: Tuesday, November 15, 2011 10:57 AM
 To: users@wicket.apache.org
 Subject: Creating a Wicket Session outside of a Wicket request

 Hey all,

 I have a requirement where I'd like to create a Wicket Session outside
 of a Wicket request:

 My application runs stand-alone (no problem here) and as a Facebook
 application. Facebook calls my REST authentication service with a user's
 credentials if they open my application in facebook. At this point I
 don't have a Wicket session, but want to signin the user in my
 AuthenticatedWebSession from wicket-auth-roles. I'm using the
 WicketSessionFilter in front of my REST service to get access to the
 session, which works fine if the session already exists. If there is no
 session, as in this case, the filter throws an IllegalArgumentException.

 Since I have access to the Wicket Application I thought about calling
 Application.get().newSession(), but this method only accepts Wicket's
 WebRequest and WebResponse objects. Is it somehow possible to bind a new
 session in a non-wicket request?

 Kind regards,

 Thomas

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org




Re: Creating a Wicket Session outside of a Wicket request

2011-11-15 Thread Thomas Heigl
That looks quite straight forward, but wouldn't I still have the same
problem I'm currently facing? The ShiroWebSession is still just a normal
wicket session that can't be created from outside the Wicket request.

Or are you suggesting to login the subject using raw Shiro and then check
in the next wicket request if the subject is authenticated and log him in
transparently?

Thomas

On Tue, Nov 15, 2011 at 8:40 PM, David Berkman david.berk...@glu.comwrote:

 Don't know. It was easy enough I just rolled my own.

 David

 -Original Message-
 From: anant.a...@gmail.com [mailto:anant.a...@gmail.com]
 Sent: Tuesday, November 15, 2011 11:36 AM
 To: users@wicket.apache.org
 Subject: Re: Creating a Wicket Session outside of a Wicket request

 That's interesting I was trying to do some thing similar n eariler and
 just dropped it. Is it possible to use wicket shiro instead?
 -Original Message-
 From: David Berkman david.berk...@glu.com
 Date: Tue, 15 Nov 2011 11:09:10
 To: users@wicket.apache.org
 Reply-To: users@wicket.apache.org
 Subject: RE: Creating a Wicket Session outside of a Wicket request

 You can integrate Shiro with auth-roles very easily. Just create
 ShiroAuthenticatedWebSession.

 package com.wicketized.extension.security;

 import java.util.LinkedList;
 import org.apache.shiro.SecurityUtils;
 import org.apache.shiro.authc.UsernamePasswordToken;
 import org.apache.shiro.subject.Subject; import
 org.apache.wicket.authroles.authentication.AuthenticatedWebSession;
 import org.apache.wicket.authroles.authorization.strategies.role.Roles;
 import org.apache.wicket.request.Request;

 public class ShiroWebSession extends AuthenticatedWebSession {

  private static final Roles NO_ROLES = new Roles();

  public ShiroWebSession (Request request) {

super(request);
  }

  @Override
  public boolean authenticate (String username, String password) {

Subject currentUser;

if (!(currentUser = SecurityUtils.getSubject()).isAuthenticated()) {

  UsernamePasswordToken token = new UsernamePasswordToken(username,
 password);

  token.setRememberMe(true);
  try {
currentUser.login(token);
  }
  catch (Exception exception) {

return false;
  }
}

return true;
  }

  @Override
  public Roles getRoles () {

Subject subject;

if (((subject = SecurityUtils.getSubject()) != null) 
 subject.isAuthenticated()) {

  LinkedListString codeList;
  String[] codes;

  codeList = new LinkedListString();
  for (RoleType roleType : RoleType.values()) {
if (subject.hasRole(roleType.getCode())) {
  codeList.add(roleType.getCode());
}
  }

  codes = new String[codeList.size()];
  codeList.toArray(codes);

  return new Roles(codes);
}

return NO_ROLES;
  }

  @Override
  public void signOut () {

SecurityUtils.getSubject().logout();
super.signOut();
  }
 }

 -Original Message-
 From: Thomas Heigl [mailto:tho...@umschalt.com]
 Sent: Tuesday, November 15, 2011 11:06 AM
 To: users@wicket.apache.org
 Subject: Re: Creating a Wicket Session outside of a Wicket request

 Hey David,

 Thanks for your reply! I have thought about using Spring Security or
 Shire, but at the moment the minimal wicket-auth-roles is enough for my
 requirements. I'd prefer to just create the session myself when I need
 it.

 Any other ideas?

 Cheers,

 THomas

 On Tue, Nov 15, 2011 at 8:02 PM, David Berkman
 david.berk...@glu.comwrote:

  Apache Shiro, and create a shiro version of WebSession. Then wicket
  can ask for the Shio Session from the Http context, and you can get it

  outside the context.
 
  David
 
  -Original Message-
  From: Thomas Heigl [mailto:tho...@umschalt.com]
  Sent: Tuesday, November 15, 2011 10:57 AM
  To: users@wicket.apache.org
  Subject: Creating a Wicket Session outside of a Wicket request
 
  Hey all,
 
  I have a requirement where I'd like to create a Wicket Session outside

  of a Wicket request:
 
  My application runs stand-alone (no problem here) and as a Facebook
  application. Facebook calls my REST authentication service with a
  user's credentials if they open my application in facebook. At this
  point I don't have a Wicket session, but want to signin the user in my

  AuthenticatedWebSession from wicket-auth-roles. I'm using the
  WicketSessionFilter in front of my REST service to get access to the
  session, which works fine if the session already exists. If there is
  no session, as in this case, the filter throws an
 IllegalArgumentException.
 
  Since I have access to the Wicket Application I thought about calling
  Application.get().newSession(), but this method only accepts Wicket's
  WebRequest and WebResponse objects. Is it somehow possible to bind a
  new session in a non-wicket request?
 
  Kind regards,
 
  Thomas
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org

WicketFilter always sets expires header to 1h for shared resources if browser sends if-modified-since header

2011-09-05 Thread Thomas Heigl
Hey all,

I've just been investigating some performance problems indicated by Page
Speed. It reported that some of my resources did not send far future expiry
headers, although my default expiry and my expiry for all resources is set
to one year.

After some debugging, I found out that Wicket always sets the expiry header
to 1 hour if the browser sends a request including an
IF-MODIFIED-SINCE-header. The relevant code is in WicketFilter (1.4.16)
347-350:

httpServletResponse.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
httpServletResponse.setDateHeader(Expires, System.currentTimeMillis()
+ Duration.hours(1).getMilliseconds());

There already is an issue for this that seems to have been fixed some time
in the past: WICKET-1748 https://issues.apache.org/jira/browse/WICKET-1748
.

However, there is currently no way to change this default expiry. Would it
be possible to re-use the web application's default cache duration or even
the actual resource cache duration?

Cheers,

Thomas


Re: WicketFilter always sets expires header to 1h for shared resources if browser sends if-modified-since header

2011-09-05 Thread Thomas Heigl
Hi Martin,

Thanks for the fast reply! Upgrading to Wicket 1.5 is on our roadmap but is
quite a lot of work for a bigger project and we most likely won't upgrade
until the final release. As we use a Wicket application managed by
JBoss-Seam, wrapping the wicket filter is not trivial either.

Is there any reason against changing the hard-coded expires header in the
filter to the application's default cache duration in one of the next minor
releases?

Cheers,

Thomas

On Mon, Sep 5, 2011 at 4:55 PM, Martin Grigorov mgrigo...@apache.orgwrote:

 Caching is improved a lot in Wicket 1.5, consider upgrading.
 You can always override headers set by Wicket by introducing your own
 servlet filter which wraps WicketFilter and resets the headers after
 WicketFilter returns, i.e. chain.doFilter() call in your filter.

 On Mon, Sep 5, 2011 at 5:42 PM, Thomas Heigl tho...@umschalt.com wrote:
  Hey all,
 
  I've just been investigating some performance problems indicated by Page
  Speed. It reported that some of my resources did not send far future
 expiry
  headers, although my default expiry and my expiry for all resources is
 set
  to one year.
 
  After some debugging, I found out that Wicket always sets the expiry
 header
  to 1 hour if the browser sends a request including an
  IF-MODIFIED-SINCE-header. The relevant code is in WicketFilter (1.4.16)
  347-350:
 
 httpServletResponse.setStatus(HttpServletResponse.SC_NOT_MODIFIED);
 httpServletResponse.setDateHeader(Expires,
 System.currentTimeMillis()
  + Duration.hours(1).getMilliseconds());
 
  There already is an issue for this that seems to have been fixed some
 time
  in the past: WICKET-1748 
 https://issues.apache.org/jira/browse/WICKET-1748
  .
 
  However, there is currently no way to change this default expiry. Would
 it
  be possible to re-use the web application's default cache duration or
 even
  the actual resource cache duration?
 
  Cheers,
 
  Thomas
 



 --
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com

 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org