wicket-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Smet <guillaume.s...@gmail.com>
Subject Re: Lock timeout per page class
Date Tue, 28 Oct 2014 23:50:03 GMT
Hi Martin,

Looks sane to me. I created a JIRA issue:
https://issues.apache.org/jira/browse/WICKET-5740 .

Thanks again for your help!

On Tue, Oct 28, 2014 at 9:45 AM, Martin Grigorov <mgrigorov@apache.org> wrote:
> Here is my version: http://pastie.org/9680245
> Please create a ticket in JIRA if you like it.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Oct 28, 2014 at 9:52 AM, Martin Grigorov <mgrigorov@apache.org>
> wrote:
>
>> Hi,
>>
>> I share Sebastien's concern.
>> I'll see how to workaround this.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Sat, Oct 25, 2014 at 2:57 PM, Sebastien <sebfz1@gmail.com> wrote:
>>
>>> 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.smet@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 <mgrigorov@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.smet@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 <
>>> mgrigorov@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.smet@gmail.com>
>>> > >> > wrote:
>>> > >> >
>>> > >> >> Hi Martin,
>>> > >> >>
>>> > >> >> On Wed, Oct 22, 2014 at 9:51 AM, Martin Grigorov <
>>> > mgrigorov@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-unsubscribe@wicket.apache.org
>>> > >> >> For additional commands, e-mail: users-help@wicket.apache.org
>>> > >> >>
>>> > >> >>
>>> > >>
>>> > >> ---------------------------------------------------------------------
>>> > >> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > >> For additional commands, e-mail: users-help@wicket.apache.org
>>> > >>
>>> > >>
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> > For additional commands, e-mail: users-help@wicket.apache.org
>>> >
>>> >
>>>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Mime
View raw message