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

Reply via email to