Mathias, me and Paul were discussing the future of this feature. For the most part we were in agreement. I appreciate your input, but it did not gain traction w/ anyone. You then went ahead and committed a bunch of code.
IMO, you have not been a good team member today Bernd. Please assign the issue to yourself. Thank you very much for your interest in getting us closer to a 1.2implementation. Dennis Byrne On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
??? Yes, I know it. Dennis Byrne wrote: > 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.2and >> > 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.2can >> >> 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
