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 20:55:50 GMT
Mathias, me and Paul were discussing the future of this feature.  For the
most part we were in agreement.  I appreciate your input, but it did not
gain traction w/ anyone.  You then went ahead and committed a bunch of code.


IMO, you have not been a good team member today Bernd.  Please assign the
issue to yourself.

Thank you very much for your interest in getting us closer to a
1.2implementation.

Dennis Byrne

On 3/3/07, Bernd Bohmann <bernd.bohmann@atanion.com> wrote:
>
> ??? Yes, I know it.
>
> Dennis Byrne wrote:
> > Are you under the impression that our 1.2 branch didn't already handle
> > @PostConstruct and @PreDestroy?  Looks like the left hand doesn't know
> what
> > the right hand is doing here.
> >
> > Dennis Byrne
> >
> > On 3/3/07, Bernd Bohmann <bernd.bohmann@atanion.com> wrote:
> >>
> >> Just added an implementation of the annotation handling based on the
> >> tomcat implementation.
> >>
> >> Bernd
> >>
> >> Dennis Byrne wrote:
> >> > I added a comment
> >> >
> >> http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192023.
> >> >
> >> > Two more ideas.  Ryan mentions applications using facelets, jsf 1.2and
> >> > servlet 2.4.  Unless I'm missing something, there's one reason to use
> >> > annotation.getName().equals("javax.annotation.PostConstruct") rather
> >> than
> >> > annotation.class == PostConstruct.class.  Also, the tomcat guys are
> >> > processing annotations even when the method is marked private.
> >> >
> >> > Dennis Byrne
> >> >
> >> > On 3/3/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> >> >>
> >> >> 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 <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.5containers 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

Mime
View raw message