On 4/28/06, Hubert Rabago <[EMAIL PROTECTED]> wrote:
On 4/28/06, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > Yes. The way to do this would be to define a phase listener for Render > Response phase, and do your data collection in the beforePhase event > handler. You also have to remember that your listener is going to receive > beforePhase() calls for *all* simultaneously active requests, not just the > one page you might be interested in. And, don't forget to deregister > yourself as a listener when the request completes, so you don't create a > memory leak. > Craig, What do you mean deregister the listener? Where is the leak from? My understanding was I register the the PhaseListener in faces-config, and the listener is active for the entire life of my application.
Sorry for not being clearer. You can indeed register a listener with a <phase-listener> declaration -- you get an application wide singleton that has the same lifetime as your application. However, it's also possible to add a phase listener programmatically, by getinng access to the Lifecycle instance (from the LifecycleFactory), and calling addPhaseListener() on it -- the standard JavaBeans event listener registration pattern. You might, for example, want to create a request scope backing bean that registers itself for phase listener events just for the duration of this request (you still have to disambiguate whether the event is for "your" request or not -- easiest way to do that is to compare the FacesContext instance included in the event to the one that was active when your backing bean was created). If you do this, but don't remember to deregister at the end of the request -- and you need to be robust in case exceptions were thrown -- then the list of phase listeners will get longer and longer. And, because there are live references to them in the Lifecycle instance, they would never be garbage collected either. In the very first version of Creator, we were experimenting with request scoped phase listeners like this, and found it easier to use the single instance approach instead. Shale's design benefits from that experience as well. Hubert Craig
