I don't hold anything against you. Ultimately I feel like this is a lose-lose situation for MyFaces because where things stand now, you are likely to feel as though your efforts on that branch are not appreciated. They are.
Ryan has responded ... http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192000 Dennis Byrne On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Sorry, I ask you if it's ok to add the code. I get no answer then I asume it's ok to add my idea. It's only a different possible implementation. If you don't like it you can remove it. Is anything wrong with the code? Bernd Dennis Byrne wrote: > 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
