struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig McClanahan" <>
Subject Re: Where dose JSP works in JSF request lifecycle?
Date Fri, 28 Apr 2006 21:28:32 GMT
On 4/28/06, Hubert Rabago <> wrote:
> On 4/28/06, Craig McClanahan <> 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



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message