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
