Are any of these class names or context params start w/ javax.faces ? If so, we can move the conversation back into the issue tracker and I'll close the @PostConstruct issue once Paul says it's good to go. I don't see the point of the system property though.
Dennis Byrne 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.5 is 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
