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