[ 
https://issues.apache.org/jira/browse/WICKET-3695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13032518#comment-13032518
 ] 

Igor Vaynberg commented on WICKET-3695:
---------------------------------------

>I don't agree with you on this. The whole idea of IRequestCycleListener was 
>that is no longer 
>needed to subclass the RequestCycle to add behavior, which makes it possible 
>for multiple 
>libraries to add behavior. Your solution breaks with this idea. 

the listener is there to make life easy for the 95% usecase. for the other 5% 
we left the ability to override this on requestcycle open. in general we highly 
discourage our users accessing objects after they have been detached - as doing 
so may inadvertently re-attach them. if you still want to do this thing we 
discourage, we left the door open...

>Also, request cycle listeners are stored in nested 
>RequestCycleListenerCollections: 
>the root collection for the RequestCycle contains the collection from the 
>application.
>Your solution will not call onDetached on the listeners registered in the 
>application.
>Implementing that will require a significant amount of code, because it is not
>possible to let RequestCycleListenerCollection implement MySpecialListener.

certainly there is potential for listeners to be wrapped, but you can check for 
that as well. you can also add your own listener collection or even your own 
listeners.


finally, this is just my opinion. you are more then welcome to start a vote on 
our dev list to have onDetached() or onDestroy() added as a standard callback. 
my vote will be -0 which is non-blocking.

> No onAfterTargetsDetached (or similar) available in IRequestCycleListener
> -------------------------------------------------------------------------
>
>                 Key: WICKET-3695
>                 URL: https://issues.apache.org/jira/browse/WICKET-3695
>             Project: Wicket
>          Issue Type: Bug
>          Components: wicket-core
>    Affects Versions: 1.5-RC4
>            Reporter: Emond Papegaaij
>            Assignee: Igor Vaynberg
>
> In Wicket 1.4, we used to override onAfterTargetsDetached to check if all 
> models in our pages are fully detached. In onEndRequest we closed the 
> hibernate session and destroyed several threadlocals. In 
> IRequestCycleListener, onEndRequest has been moved to execute before 
> onDetach, and nothing executes after detach. The order in Wicket 1.4 was 
> detach, onAfterTargetsDetached, onEndRequest, in Wicket 1.5 it has become 
> onEndRequest, onDetach. This gives no place to run code after the detach, 
> whereas Wicket 1.4 provided 2 options. In my opinion, either a new method 
> should be added (onRequestDestroyed?) or onEndRequest should be moved to 
> execute after onDetach (which, to me, makes more sense).
> The current behavior makes it very difficult to work with request cycle 
> listeners. For example, we can't close the hibernate session before pages are 
> detached. Some of our models use the hibernate session during detach to 
> record changes made to the objects stored in these models. This will fail if 
> the hibernate session is already closed. Also, the detach-checker needs to 
> run after the pages are detached. The only solutions for these problems I can 
> think of right now is not to use request cycle listeners or to use a custom 
> IRequestCycleProvider, which adds the listeners even before the wicket 
> internal ones.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to