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.5 containers 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
