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
