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 >> > >> > >> > >
