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