Re: Lock timeout per page class

2014-10-28 Thread Martin Grigorov
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 seb...@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.s...@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 mgrigo...@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.s...@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 
 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 IProviderPageAccessSynchronizer
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
  
  
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 



Re: Lock timeout per page class

2014-10-28 Thread Martin Grigorov
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 mgrigo...@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 seb...@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.s...@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 mgrigo...@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.s...@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 
 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 IProviderPageAccessSynchronizer
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
  
  
 
  

Re: Lock timeout per page class

2014-10-28 Thread Guillaume Smet
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 mgrigo...@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 mgrigo...@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 seb...@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.s...@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 mgrigo...@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.s...@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 
 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 IProviderPageAccessSynchronizer
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
   
   

Re: Lock timeout per page class

2014-10-25 Thread Guillaume Smet
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 mgrigo...@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.s...@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 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 IProviderPageAccessSynchronizer
  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



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



Re: Lock timeout per page class

2014-10-25 Thread Sebastien
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.s...@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 mgrigo...@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.s...@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 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 IProviderPageAccessSynchronizer
   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
 
 

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




Re: Lock timeout per page class

2014-10-24 Thread Martin Grigorov
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 IProviderPageAccessSynchronizer
 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




Re: Lock timeout per page class

2014-10-24 Thread Guillaume Smet
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 IProviderPageAccessSynchronizer
 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



Re: Lock timeout per page class

2014-10-24 Thread Martin Grigorov
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.s...@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 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 IProviderPageAccessSynchronizer
  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




Re: Lock timeout per page class

2014-10-23 Thread Guillaume Smet
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 IProviderPageAccessSynchronizer 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



Re: Lock timeout per page class

2014-10-22 Thread Martin Grigorov
Hi,

You are right!

On Tue, Oct 21, 2014 at 11:11 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:

 Hi Martin,

 On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org
 wrote:
  You can
  use
 org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
  to check what is the requested page in your
  own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

 Cute trick but it doesn't work: the timeout is determined once and for
 all when the PageAccessSynchronizer is instantiated (see
 Session$PageAccessSynchronizerProvider).

 And AFAICS, the PageAccessSynchronizer is too low level to be a good
 place to manipulate the RequestCycle. Or am I wrong?


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

Is this good enough ?



 --
 Guillaume

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




Re: Lock timeout per page class

2014-10-21 Thread Martin Grigorov
Hi Guillaume,

You can
use org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
to check what is the requested page in your
own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov

On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet guillaume.s...@gmail.com
wrote:

 Hi,

 We have a few pages in our application which might take a long time to
 generate. This is definitely not the usual case but there are a few of
 them.

 Thus we were forced to define a high lockTimeout to be sure these
 pages can be served.

 The fact is that we would really like to have a far lower default
 timeout except for these pages.

 Is there a way to configure the lockTimeout on a per page basis (I
 haven't found one)?

 If not, would it be a good idea to provide a way to do so?

 Thanks for your feedback.

 --
 Guillaume

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




Re: Lock timeout per page class

2014-10-21 Thread Guillaume Smet
Thanks Martin!

We will give it a try and post what we got.

-- 
Guillaume

On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote:
 Hi Guillaume,

 You can
 use 
 org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
 to check what is the requested page in your
 own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

 Martin Grigorov
 Wicket Training and Consulting
 https://twitter.com/mtgrigorov

 On Tue, Oct 21, 2014 at 1:12 PM, Guillaume Smet guillaume.s...@gmail.com
 wrote:

 Hi,

 We have a few pages in our application which might take a long time to
 generate. This is definitely not the usual case but there are a few of
 them.

 Thus we were forced to define a high lockTimeout to be sure these
 pages can be served.

 The fact is that we would really like to have a far lower default
 timeout except for these pages.

 Is there a way to configure the lockTimeout on a per page basis (I
 haven't found one)?

 If not, would it be a good idea to provide a way to do so?

 Thanks for your feedback.

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



Re: Lock timeout per page class

2014-10-21 Thread Guillaume Smet
Hi Martin,

On Tue, Oct 21, 2014 at 1:19 PM, Martin Grigorov mgrigo...@apache.org wrote:
 You can
 use 
 org.apache.wicket.request.cycle.PageRequestHandlerTracker#getFirstHandler()
 to check what is the requested page in your
 own org.apache.wicket.settings.def.RequestCycleSettings#getTimeout

Cute trick but it doesn't work: the timeout is determined once and for
all when the PageAccessSynchronizer is instantiated (see
Session$PageAccessSynchronizerProvider).

And AFAICS, the PageAccessSynchronizer is too low level to be a good
place to manipulate the RequestCycle. Or am I wrong?

-- 
Guillaume

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