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 Sat, 03 Mar 2007 16:47:04 GMT
On 3/3/07, Bernd Bohmann <bernd.bohmann@atanion.com> 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 <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.2can
> >> > 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