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