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
