Hi Martin, Looks sane to me. I created a JIRA issue: https://issues.apache.org/jira/browse/WICKET-5740 .
Thanks again for your help! On Tue, Oct 28, 2014 at 9:45 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Here is my version: http://pastie.org/9680245 > Please create a ticket in JIRA if you like it. > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > >> Hi, >> >> I share Sebastien's concern. >> I'll see how to workaround this. >> >> Martin Grigorov >> Wicket Training and Consulting >> https://twitter.com/mtgrigorov >> >> On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <seb...@gmail.com> wrote: >> >>> Hi Guillaume, >>> >>> Generally speaking, you cannot call a non final method from a >>> constructor... >>> >>> Best regards, >>> Sebastien >>> On Oct 25, 2014 1:32 PM, "Guillaume Smet" <guillaume.s...@gmail.com> >>> wrote: >>> >>> > Hi Martin, >>> > >>> > I got something working with the following changes in Wicket: >>> > >>> > >>> https://github.com/openwide-java/wicket/commit/6374a4a7c6fb66841143a88933523f97305cf1a4 >>> > >>> > Do you consider this commitable? If so, I can create a JIRA issue and >>> push >>> > a PR. >>> > >>> > Having the pageId in the getTimeout call is quite nice as I don't have >>> > to get it again from the PageRequestHandlerTracker. >>> > >>> > Thanks for your feedback. >>> > >>> > On Fri, Oct 24, 2014 at 9:16 AM, Martin Grigorov <mgrigo...@apache.org> >>> > wrote: >>> > > If you have a base page then BasePage#onInitialize() should be a good >>> > place. >>> > > Or you could add the pageIds of the special/slow pages only in the >>> map. >>> > > >>> > > Otherwise you may use PageRequestHandlerTracker#getLastHandler in a >>> > custom >>> > > IRequestCycleListener#onDetach(). >>> > > >>> > > Martin Grigorov >>> > > Wicket Training and Consulting >>> > > https://twitter.com/mtgrigorov >>> > > >>> > > On Fri, Oct 24, 2014 at 10:11 AM, Guillaume Smet < >>> > guillaume.s...@gmail.com> >>> > > wrote: >>> > > >>> > >> Hi Martin, >>> > >> >>> > >> Yeah, I thought about that too but I'm not sure of the best place to >>> > >> build the pageId -> pageClassName map. Any advice about this? >>> > >> >>> > >> Once I'll get this working, I'll build a PR for the few changes I >>> made >>> > >> in Wicket (based on what you proposed earlier). Would be nice to have >>> > >> them in 6.18. >>> > >> >>> > >> On Fri, Oct 24, 2014 at 8:59 AM, Martin Grigorov < >>> mgrigo...@apache.org> >>> > >> wrote: >>> > >> > Hi Guillaume, >>> > >> > >>> > >> > Sorry for not thinking more carefully about this the first time! >>> > >> > I'm afraid it is not possible to do it the way I suggested. >>> > >> > PageAccessSynchronizer is the entry point to start using a page >>> and it >>> > >> > works only with pageId! >>> > >> > >>> > >> > Here is a new hackish approach: >>> > >> > Store pageId -> pageClassName map in the Session. Then when >>> > >> > PageAccessSynchronizer is requested to lock a page by id use that >>> id >>> > to >>> > >> > resolve the class name and to decide what timeout to use. >>> > >> > >>> > >> > Martin Grigorov >>> > >> > Wicket Training and Consulting >>> > >> > https://twitter.com/mtgrigorov >>> > >> > >>> > >> > On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet < >>> > >> guillaume.s...@gmail.com> >>> > >> > wrote: >>> > >> > >>> > >> >> Hi Martin, >>> > >> >> >>> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov < >>> > mgrigo...@apache.org> >>> > >> >> wrote: >>> > >> >> > I'd like to avoid moving the logic that gets the timeout from >>> > >> >> > Session.PageAccessSynchronizerProvider to PageAccessSynchronizer >>> > >> because >>> > >> >> > this way it will use Application.get() everytime and most apps >>> > don't >>> > >> need >>> > >> >> > to pay for this. >>> > >> >> > >>> > >> >> > A way to make it possible for you is to remove the 'final' >>> > >> >> > from org.apache.wicket.Session#getPageManager and introduce >>> > >> overridable >>> > >> >> > PageAccessSynchronizer#getTimeout(). This way you can use your >>> own >>> > >> >> > PageAccessSynchronizer. >>> > >> >> > http://pastie.org/9667070 >>> > >> >> >>> > >> >> After a few experiments, here I am! >>> > >> >> >>> > >> >> So, it mostly works: I thought it would be better to add something >>> > like: >>> > >> >> protected IProvider<PageAccessSynchronizer> >>> > >> >> newPageAccessSynchronizerProvider() >>> > >> >> { >>> > >> >> return new PageAccessSynchronizerProvider(); >>> > >> >> } >>> > >> >> in Session and call it from the constructor instead of removing >>> the >>> > >> >> final so I did that in my code. >>> > >> >> >>> > >> >> It works pretty well BUT I haven't found a way to get the page >>> class >>> > >> >> in getTimeout without having the risk to trigger a >>> > resolvePageInstance >>> > >> >> which will try to lock and then call getTimeout leading to a >>> > wonderful >>> > >> >> stack overflow exception when dealing with >>> > >> >> ListenerInterfaceRequestHandler. >>> > >> >> >>> > >> >> Obviously (...) what interests me the most is the getTimeout in >>> > >> >> ListenerInterfaceRequestHandler as it's often actions on buttons >>> > which >>> > >> >> are long to run. >>> > >> >> >>> > >> >> Here is what I have in mind for my Session class: >>> > >> >> https://gist.github.com/gsmet/3b9e2775d25fadcef5ef >>> > >> >> >>> > >> >> I must admit that an advice would be welcome as I wouldn't like to >>> > >> >> have stack overflow errors popping out in weird edge cases. >>> > >> >> >>> > >> >> Thanks! >>> > >> >> >>> > >> >> -- >>> > >> >> Guillaume >>> > >> >> >>> > >> >> >>> --------------------------------------------------------------------- >>> > >> >> 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 >>> > >>> > >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
