Re: Wicket 10 Release Plans
+1 for M2 and a final release as soon as possible. I also have no plans of adding anything to Wicket 10 before the release. I would have deployed M1 to production already if my Jakarta migration wasn't blocked by performance issues in Hibernate 6 ,) Best, Thomas On Mon, Sep 11, 2023 at 3:30 PM Martin Grigorov wrote: > On Mon, Sep 11, 2023 at 4:13 PM Korbinian Bachl < > korbinian.ba...@whiskyworld.de> wrote: > > > +1 for M2 or maybe even a RC1 if no big changes are outstanding? > > > > Usually I dont care for latest wicket versions (we stayed on 6 way too > > long :D), > > but since the JavaEE -> JakartaEE this is a showstopper for us as you > even > > cant access anything HTTPSession related as you include the jakarta-api > on > > jakarta.* > > namespace but wicket 9 only delivers javax.* results > > > > Or if this really takes a year to release maybe a wicket-9-jakarta > version? > > > > Anyone can migrate his/her Javax based application to Jakarta now via > migration tools like https://github.com/apache/tomcat-jakartaee-migration > It is a bytecode translator and has been tested with Wicket application > several years ago! > > > > > > > > > - Ursprüngliche Mail - > > > Von: "Martin Grigorov" > > > An: "users" > > > Gesendet: Montag, 11. September 2023 13:00:46 > > > Betreff: Re: Wicket 10 Release Plans > > > > > On Mon, Sep 11, 2023 at 11:06 AM Andrea Del Bene > > > > wrote: > > > > > >> Hi, > > >> > > >> as usual it's not easy making precise plans for the future since many > > of us > > >> (probably all of us) works on Wicket on a voluntary base. However, for > > the > > >> imminent future we are about to release Wicket 10 M2 and check that > > >> everything is fine with the new dependency on Commons FileUpload M1. > > After > > >> > > > > > > +1 for M2 to re-test the latest dependencies updates (fileupload and > > > others) ! > > > > > > > > >> this step we might be ready for a GA release of Wicket 10, but there > are > > >> some necessary steps (make a public announce, update the site, etc...) > > that > > >> make it quite unlikely to release it before the end of the year. At > the > > >> > > > > > > Next year ?! > > > I really do not understand why it has to be delayed so much when there > is > > > almost no active work on Wicket! > > > Kudos to Maxim for working on the FileUpload issue! But apart from > that I > > > don't see any plans for working on anything major that could not be > > > introduced in a minor version! > > > The official announcement (coordinated with press@a.o) has proved to > be > > an > > > issue for the last few major releases! I'd rather go without it than > > delay > > > the release for half a year. > > > > > > > > >> moment I don't have elements to be more precise, but probably after > the > > M2 > > >> we will have a clearer view of the next steps toward a final release. > > >> > > >> Andrea. > > >> > > >> On Mon, Sep 11, 2023 at 8:18 AM Korbinian Bachl < > > >> korbinian.ba...@whiskyworld.de> wrote: > > >> > > >> > Hi Fellow Wicket-Devs! > > >> > > > >> > I'd like to also ask this question as wicket is the only part that > > holds > > >> > us back from jumping up to JakartaEE (currently JavaEE 8). > > >> > > > >> > Any eta on final release? > > >> > > > >> > - Ursprüngliche Mail - > > >> > > Von: "Tony Tkacik" > > >> > > An: "users" > > >> > > Gesendet: Donnerstag, 7. September 2023 13:54:41 > > >> > > Betreff: Wicket 10 Release Plans > > >> > > > >> > > Hi, > > >> > > we are using Wicket 10 M1 for few months and we plan to release > LTS > > of > > >> > our open > > >> > > source project midPoint 4.8 on 17 October 2023, > > >> > > are there any concrete plans about release timeframe of Wicket 10? > > >> > > > > >> > > Thanks > > >> > > Anton Tkacik > > >> > > > >> > > - > > >> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > >> > For additional commands, e-mail: users-h...@wicket.apache.org > > >> > > > >> > > > >> > > >> -- > > >> Andrea Del Bene. > > >> Apache Wicket committer. > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > >
Re: Page locked for a long time
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
> > 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
`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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)?
+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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
