myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mathias Brökelmann" <mbroekelm...@googlemail.com>
Subject Re: @PreDestroy, Servlet API,
Date Fri, 02 Mar 2007 23:24:44 GMT
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 <dennis@dbyrne.net>:
> 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 <mbroekelmann@googlemail.com> 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 <paulmcmahan@gmail.com>:
> > > 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 <dennis@dbyrne.net> 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 <paulmcmahan@gmail.com> 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 <dennis@dbyrne.net> 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 < paulmcmahan@gmail.com> 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 < dennis@dbyrne.net> 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 < paulmcmahan@gmail.com>
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 < dennis@dbyrne.net>
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

Mime
View raw message