myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Byrne" <den...@dbyrne.net>
Subject Re: @PreDestroy, Servlet API,
Date Fri, 02 Mar 2007 23:35:58 GMT
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 <mbroekelmann@googlemail.com> 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 <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.5is
> > 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
>



-- 
Dennis Byrne

Mime
View raw message