Actually by "dependency injection" I'm specifically referring to the portion of the JSF spec that discusses injecting resources where certain annotations are found in a managed bean. So, while scanning for the @PreConstruct and @PostDestroy annotations MyFaces would also scan for @EJB, @Resource, @WebServiceRef, etc and then time the invocation of @PreConstruct and @PostDestroy to support the injection.
Tomcat provides an example of how this can be done. The following class scans for annotations when a web app starts: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java And then this class handles the injection and calling the PostConstruct and PreDestroy methods when an servlet, filter, or listener is brought into service: http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java Would it make sense for MyFaces to follow a similar approach for managed beans? Also, I'm curious why you're hoping to avoid importing classes from javax.annotation classes since servlet 2.5 containers are required to support them. Is this so that MyFaces 1.2 can support servlet 2.4 containers? Best wishes, Paul On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote:
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
