Are you under the impression that our 1.2 branch didn't already handle @PostConstruct and @PreDestroy? Looks like the left hand doesn't know what the right hand is doing here.
Dennis Byrne On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Just added an implementation of the annotation handling based on the tomcat implementation. Bernd Dennis Byrne wrote: > I added a comment > http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023 . > > Two more ideas. Ryan mentions applications using facelets, jsf 1.2 and > servlet 2.4. Unless I'm missing something, there's one reason to use > annotation.getName().equals("javax.annotation.PostConstruct") rather than > annotation.class == PostConstruct.class. Also, the tomcat guys are > processing annotations even when the method is marked private. > > Dennis Byrne > > On 3/3/07, Paul McMahan <[EMAIL PROTECTED]> wrote: >> >> OK, I think the RI also recently added the META-INF/services >> technique. But I don't know how reliable this sun blog entry is: >> http://tinyurl.com/yrrjs2 >> >> Best wishes, >> Paul >> >> On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: >> > The RI uses two ways to lookup the implementation of the vendor >> > specific implementation of the InjectionProvider. They first try to >> > use a web context init param and if that is not configured they simply >> > use a system property. Both keyed by the class name of the >> > InjectionProvider interface. >> > >> > 2007/3/2, Paul McMahan <[EMAIL PROTECTED]>: >> > > I think Mathias' suggestion is right on. I haven't looked at the RI >> > > code but I read somewhere that it passes the name of >> > > InjectionProviders via entries in META-INF/services. If MyFaces used >> > > a similar approach I think it should work OK for Geronimo and just >> > > about any other container that supports injection, And it should >> also >> > > make MyFaces more interchangeable with the RI. >> > > >> > > Best wishes, >> > > Paul >> > > >> > > On 3/2/07, Dennis Byrne <[EMAIL PROTECTED]> wrote: >> > > > Similar to what Mathias mentioned? >> > > > >> > > > http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337 >> > > > >> > > > It's not much work (on our side) but it sounds pretty vendor >> specific. >> > > > Again, I don't have a better solution. Mathias writes "which is >> implemented >> > > > by j2ee containers". I wonder if each container will end up >> looking >> for >> > > > different interfaces. How would MyFaces find Geronimo's >> implementation ? A >> > > > context parameter? A for loop like this ... >> > > > >> > > > String[] providers = new String[]{"org,apache.geronimo.DIProvider ", >> > > > "com.bea.DIProvider", "org.jboss.DIProvider"} >> > > > >> > > > for(String clazz : providers){ >> > > > try{ >> > > > return ClassUtils.load (clazz) >> > > > }catch(){} >> > > > } >> > > > >> > > > Dennis Byrne >> > > > >> > > > >> > > > On 3/1/07, Paul McMahan <[EMAIL PROTECTED]> wrote: >> > > > > OK, I think your interpretation of the spec makes sense and >> there's >> > > > > one particular aspect we should discuss a little further. >> > > > > >> > > > > The container doesn't know which classes are managed beans so it >> > > > > wouldn't know when to intercept the instantiation process to >> perform >> > > > > injection. What would you all think about MyFaces providing an >> > > > > interface that containers could implement to perform injection on >> a >> > > > > managed bean when MyFaces brings that bean into service? This >> would >> > > > > allow MyFaces to maintain control of the timing while allowing >> the >> > > > > container to scan for annotations and handle injection when >> prompted >> > > > > to do so. >> > > > > >> > > > > Best wishes, >> > > > > Paul >> > > > > >> > > > > >> > > > > On 2/26/07, Dennis Byrne <[EMAIL PROTECTED]> wrote: >> > > > > > I know the specs can be vague sometimes, but I don't interpret >> the first >> > > > > > paragraph of section 5.4 as meaning the JSF implementation is >> > > > responsible >> > > > > > for @EJB, @Resources, etc. The JSF spec specifically mentions >> "the >> > > > > > container to inject references". If Geronimo can intercept the >> > > > > > instantiation of these classes in the classloader (something I >> know >> > > > nothing >> > > > > > about right now), I think we are all good here. Wouldn't >> MyFaces then >> > > > be >> > > > > > observing the requirements (in plain java) around >> @PostConstruct >> after >> > > > > > Geronimo had injected the resources? >> > > > > > >> > > > > > I think the JSF impl is only responsible for @PostConstruct and >> > > > @Predestroy. >> > > > > > This makes sense because scoped (request, session, >> application) >> are the >> > > > > > only candidates for this, and it would be more awkward to do >> that from >> > > > the >> > > > > > container. I say all of this in an open manner, so anyone feel >> free to >> > > > > > discuss. >> > > > > > >> > > > > > You're point about javax.annotation being in the Servlet 2.5is >> taken. >> > > > I >> > > > > > totally missed that. >> > > > > > >> > > > > > >> > > > > > Dennis Byrne >> > > > > > >> > > > > > On 2/26/07, Paul McMahan <[EMAIL PROTECTED]> wrote: >> > > > > > > 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.5containers 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 >> > > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > -- >> > > > > > Dennis Byrne >> > > > > >> > > > >> > > > >> > > > >> > > > -- >> > > > Dennis Byrne >> > > >> > >> > >> > -- >> > Mathias >> > >> > > >
-- Dennis Byrne
