I ended up going with Servlet/Request/Context attribute listeners for @PreDestroy. This did not involve importing javax.annotation.PreDestroy, so people w/out application servers don't have to worry about ClassDefNotFoundErrors. This also keeps us compatible with the reference implementation in terms of timing, although I really wish they'd change the wording in the spec.
Dennis Byrne On 2/26/07, Paul McMahan <[EMAIL PROTECTED]> wrote:
Sorry if I'm behind on this discussion but what are the current thoughts on how dependency injection will be implemented for managed beans? The reason I'm curious is because PreDestroy and PostConstruct annotations are used to deal with injected resources, so from a timing perspective it would be important to process all these annotations accordingly. Best wishes, Paul On 2/24/07, Dennis Byrne <[EMAIL PROTECTED]> wrote: > I'm weighing options about invoking @PreDestroy methods (@PostConstruct is > done BTW). I haven't made up my mind yet but here's where I'm at on this. > > As far as *when* this happens, the request is easy, in > FacesServelet.service(). Session and app scope are more difficult decisions. > A new HttpSessionActivationListener.attributeRemoved and a > new ServletContextAttributeListener.attributeRemoved() seem > like nice solutions, but this doesn't meet the spec requirements for 5.4.1. > The methods have to be invoked *before* the bean is pulled from scope and > the servlet API does not provide a > ServletContextAttributeListener.attribute_WILL_BE_Removed() > or a > HttpSessionActivationListener.attribute_WILL_BE_Removed (). > Also, I say *new* ServletContextAttributeListener and because > StartupServletContextListener (already in code base) implements > ServletContextListener, not > ServletContextAttributeListener. > > The other side of the problem is *how* to invoke each @PreDestroy method, > much easier. Iterating over the attributes at each scope level is trivial, > and so is determining if the bean's class is a managed bean class. But this > does not mean the *instance* was placed there by the JSF implementation. > Using a list (at each level of scope) to track managed instances solves the > problem, as long as you sync on the session (only one time per session) in > order to avoid concurrency issues; it also means three more data structures > in memory. > > -- > Dennis Byrne
-- Dennis Byrne
