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

On Thu, Oct 23, 2014 at 5:44 PM, Guillaume Smet <guillaume.s...@gmail.com>

> 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

Reply via email to