On 3/3/07, Bernd Bohmann <[EMAIL PROTECTED]> wrote:
Hello Dennis, why we should look at the RI?
I'd prefer doing things that is compatible with them. This is easier on the users and it makes passing TCK smoother. Can we use this Interface
http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html ?
I'd prefer something that would work on other Servlet containers. I am open to ideas. Why you don't like to import javax.annotation. in the code. If the
annotation are missing in the container the annotations in the managed bean would be meaningless. But maybe the annotation are required by the servlet spec.
I didn't do this for users who were using @PostConstruct in their managed beans, I did this to avoid ClassDefNotFoundErrors for users who *didn't* use @PostConstruct. However Paul has already pointed out in this thread that this is not realistic, since Servlet 2.5 requires these annotations. Why you create a own class for each Listener?
Regards
Bernd Dennis Byrne wrote: > As much as I agree w/ you about how better things would be if this were in > the spec, and as much as I hate to "bow down" here, I am actually OK with > using com.sun.faces.spi.InjectionProvider as the parameter in MyFaces as > well ... for the sake of users. If anyone has a problem w/ it, we can go > with org.apache.myfaces.InjectionProvider. > > Dennis Byrne > > On 3/2/07, Mathias Brökelmann <[EMAIL PROTECTED]> wrote: >> >> The RI looks for "com.sun.faces.spi.InjectionProvider" for a class >> name which implements this interface. It would have been very nice if >> this is part of the spec. But that is not the case so we need to find >> a way to support any kind of j2ee container. IMO injecting j2ee >> resources without knowing where these resources can be found is not >> possible. Therefore myfaces should call an InjectionProvider which >> simply do this job. >> >> 2007/3/3, Dennis Byrne <[EMAIL PROTECTED]>: >> > 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.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.5 >> > containers 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 >> >> >> -- >> Mathias >> > > >
-- Dennis Byrne
