@PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

I don't hold anything against you.  Ultimately I feel like this is a
lose-lose situation for MyFaces because where things stand now, you are
likely to feel as though your efforts on that branch are not appreciated.
They are.

Ryan has responded ...
http://blogs.sun.com/rlubke/entry/jsf_ri_1_2_and#comment-1172947192000

Dennis Byrne

On 3/3/07, Bernd Bohmann <be...@atanion.com> wrote:
>
> Sorry,
> I ask you if it's ok to add the code.
> I get no answer then I asume it's ok to add my idea.
>
> It's only a different possible implementation.
> If you don't like it you can remove it.
> Is anything wrong with the code?
>
> Bernd
>
>
>
> Dennis Byrne wrote:
> > 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

On 3/3/07, Bernd Bohmann <be...@atanion.com> wrote:
>
> Hello Dennis,
>
> should i readd the other possible implementation? :-)
> But I should write my own TestCases.


I'm not sure what you mean here Bernd.

The AnnotationProcessor/InjectionProvider are very similar. I don't like
> to define a new myfaces Interface for this use case. I would prefer the
> org.apache.AnnotationProcessor because is not tomcat specific and an
> apache implementation. Until we find a final solution we should only
> copy the code.


Yeah, it makes sense.  Please assign the issue to yourself if/when you begin
the work.

It's no problem to use the annotation name instead of using the class.
> But personal i prefer the class.

Regards
>
> Bernd
>
>
> Dennis Byrne wrote:
> > On 3/3/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
> >>
> >> No code in myfaces (or any other apache project) is owned by someone.
> >> That is important for a healthy and moving community. Bernds
> >> submission was a little bit fast but sometimes a complex issue is
> >> better understand if we can look at the code - no matter if that is
> >> the solution we finally have.
> >
> >
> > I hope you did not get the idea that this was about territory here.
> >
> > How about this solution:
> >>
> >> We define a myfaces specific interface of an
> >> AnnotationProcessor/InjectionProvider which will be used throughout
> >> the code in myfaces. The initialization code lookups an implementation
> >> for that interface. If there is nothing found (through context param,
> >> META-INF/service, etc.) we implement some fallback strategies to
> >> either looking for a InjectionProvider implementation for suns RI or
> >> if that also fails we try to lookup container specific implementations
> >> like tomcats AnnotationProcessor implementation. If all fails we
> >> supply a default implementation which only handles @PostConstruct and
> >> @PreDestroy annotations - I don't think that it is possible to inject
> >> any resource w/o knowing how to lookup these.
> >
> >
> > This sounds very similar to what Ryan just talked about in his blog.
> > Bernd,
> > if are happy w/ this and still interested, feel free to go forward with
> > this.  If you still want to, I ask that the default implementation uses
> the
> > annotation name, rather than the annotation.  This gives Tomcat
> > 5.5/Facelets
> > users fewer headaches.
> >
> > Do either of you have a problem w/ the context listener doing a
> classpath
> > search for well known injection providers?  I meet a lot of devs who
> find
> > JSF too configuration heavy.
> >
> > Bernd if you don't get around to doing this, I will just end up doing it
> > sometime next week.
> >
> > 2007/3/3, Bernd Bohmann <be...@atanion.com>:
> >> > Sorry,
> >> > I ask you if it's ok to add the code.
> >> > I get no answer then I asume it's ok to add my idea.
> >> >
> >> > It's only a different possible implementation.
> >> > If you don't like it you can remove it.
> >> > Is anything wrong with the code?
> >> >
> >> > Bernd
> >> >
> >> >
> >> >
> >> > Dennis Byrne wrote:
> >> > > 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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
> >> > >> >> >> >
> >> > >> >> >>
> >> > >> >> >
> >> > >> >> >
> >> > >> >> >
> >> > >> >>
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >>
> >> > >
> >> > >
> >> > >
> >> >
> >>
> >>
> >> --
> >> Mathias
> >>
> >
> >
> >
>



-- 
Dennis Byrne

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

> Unfortunately, I don't see a way to do non proprietary
> annotation/injection processing, since the component that has to do it
> (JSP or JSF) cannot possibly get the configuration (which could define
> overrides, etc). Since I suppose you'll want to support all containers,
> that's a problem. (It would have been solved if the servlet spec had
> defined an interface like InjectionProvider in javax.servlet, of course.)


This is going to go down in the same category as inter Portlet communication
and j2ee 1.4 web services deployment.

> It's no problem to use the annotation name instead of using the class.
> > But personal i prefer the class.
>
> Rémy
>



-- 
Dennis Byrne

Re: @PreDestroy, Servlet API,

[Jacob Hookom <ja...@hookom.net>]

There were a few of us that wanted to push back on the WebTier EG around 
annotation support over the fact that there wasn't a clear API 
provided-- yet oddly enough, everyone is ending up with basically the 
same API :-)

My hope is that the WebBeans JSR can bring some solidarity around this 
through an injection API which other 'legacy' APIs can simply defer to 
(Similar to ELResolver).

It is tricky from a JSF standpoint, especially with session clustering-- 
but would WeakReference with your own ReferenceQueue fix this problem of 
associating the @PreDestroy event?

-- Jacob

Remy Maucherat wrote:
> Bernd Bohmann wrote:
>> The AnnotationProcessor/InjectionProvider are very similar. I don't 
>> like to define a new myfaces Interface for this use case. I would 
>> prefer the org.apache.AnnotationProcessor because is not tomcat 
>> specific and an apache implementation. Until we find a final solution 
>> we should only copy the code.
>
> I just had a look at InjectionProvider, and somehow the API is 
> identical to AnnotationProcessor. It did not start that way, and I did 
> not look at InjectionProvider at all (so I suppose it means the API 
> makes sense :D). The interface is used by Catalina (the Servlet 
> container) and also Jasper (Jasper gets the implementation using a 
> specific context attribute).
>
> Unfortunately, I don't see a way to do non proprietary 
> annotation/injection processing, since the component that has to do it 
> (JSP or JSF) cannot possibly get the configuration (which could define 
> overrides, etc). Since I suppose you'll want to support all 
> containers, that's a problem. (It would have been solved if the 
> servlet spec had defined an interface like InjectionProvider in 
> javax.servlet, of course.)
>
>> It's no problem to use the annotation name instead of using the 
>> class. But personal i prefer the class.
>
> Rémy
>

Re: @PreDestroy, Servlet API,

[Remy Maucherat <re...@apache.org>]

Bernd Bohmann wrote:
> The AnnotationProcessor/InjectionProvider are very similar. I don't like 
> to define a new myfaces Interface for this use case. I would prefer the 
> org.apache.AnnotationProcessor because is not tomcat specific and an 
> apache implementation. Until we find a final solution we should only 
> copy the code.

I just had a look at InjectionProvider, and somehow the API is identical 
to AnnotationProcessor. It did not start that way, and I did not look at 
InjectionProvider at all (so I suppose it means the API makes sense :D). 
The interface is used by Catalina (the Servlet container) and also 
Jasper (Jasper gets the implementation using a specific context attribute).

Unfortunately, I don't see a way to do non proprietary 
annotation/injection processing, since the component that has to do it 
(JSP or JSF) cannot possibly get the configuration (which could define 
overrides, etc). Since I suppose you'll want to support all containers, 
that's a problem. (It would have been solved if the servlet spec had 
defined an interface like InjectionProvider in javax.servlet, of course.)

> It's no problem to use the annotation name instead of using the class. 
> But personal i prefer the class.

Rémy

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

Hello Dennis,

should i readd the other possible implementation? :-)
But I should write my own TestCases.

I think it should be possible to use the PostConstruct and PreDestroy 
Annotations with tomcat 5.5 and facelets. When a InitialContext is 
available we should try resource injection, too. But it should be 
possible to add a own Provider for a container.

The AnnotationProcessor/InjectionProvider are very similar. I don't like 
to define a new myfaces Interface for this use case. I would prefer the 
org.apache.AnnotationProcessor because is not tomcat specific and an 
apache implementation. Until we find a final solution we should only 
copy the code.

It's no problem to use the annotation name instead of using the class. 
But personal i prefer the class.

Regards

Bernd


Dennis Byrne wrote:
> On 3/3/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
>>
>> No code in myfaces (or any other apache project) is owned by someone.
>> That is important for a healthy and moving community. Bernds
>> submission was a little bit fast but sometimes a complex issue is
>> better understand if we can look at the code - no matter if that is
>> the solution we finally have.
> 
> 
> I hope you did not get the idea that this was about territory here.
> 
> How about this solution:
>>
>> We define a myfaces specific interface of an
>> AnnotationProcessor/InjectionProvider which will be used throughout
>> the code in myfaces. The initialization code lookups an implementation
>> for that interface. If there is nothing found (through context param,
>> META-INF/service, etc.) we implement some fallback strategies to
>> either looking for a InjectionProvider implementation for suns RI or
>> if that also fails we try to lookup container specific implementations
>> like tomcats AnnotationProcessor implementation. If all fails we
>> supply a default implementation which only handles @PostConstruct and
>> @PreDestroy annotations - I don't think that it is possible to inject
>> any resource w/o knowing how to lookup these.
> 
> 
> This sounds very similar to what Ryan just talked about in his blog.  
> Bernd,
> if are happy w/ this and still interested, feel free to go forward with
> this.  If you still want to, I ask that the default implementation uses the
> annotation name, rather than the annotation.  This gives Tomcat 
> 5.5/Facelets
> users fewer headaches.
> 
> Do either of you have a problem w/ the context listener doing a classpath
> search for well known injection providers?  I meet a lot of devs who find
> JSF too configuration heavy.
> 
> Bernd if you don't get around to doing this, I will just end up doing it
> sometime next week.
> 
> 2007/3/3, Bernd Bohmann <be...@atanion.com>:
>> > Sorry,
>> > I ask you if it's ok to add the code.
>> > I get no answer then I asume it's ok to add my idea.
>> >
>> > It's only a different possible implementation.
>> > If you don't like it you can remove it.
>> > Is anything wrong with the code?
>> >
>> > Bernd
>> >
>> >
>> >
>> > Dennis Byrne wrote:
>> > > 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
>> > >> >> >> >
>> > >> >> >>
>> > >> >> >
>> > >> >> >
>> > >> >> >
>> > >> >>
>> > >> >
>> > >> >
>> > >> >
>> > >>
>> > >
>> > >
>> > >
>> >
>>
>>
>> -- 
>> Mathias
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

On 3/3/07, Mathias Brökelmann <mb...@googlemail.com> wrote:
>
> No code in myfaces (or any other apache project) is owned by someone.
> That is important for a healthy and moving community. Bernds
> submission was a little bit fast but sometimes a complex issue is
> better understand if we can look at the code - no matter if that is
> the solution we finally have.


I hope you did not get the idea that this was about territory here.

How about this solution:
>
> We define a myfaces specific interface of an
> AnnotationProcessor/InjectionProvider which will be used throughout
> the code in myfaces. The initialization code lookups an implementation
> for that interface. If there is nothing found (through context param,
> META-INF/service, etc.) we implement some fallback strategies to
> either looking for a InjectionProvider implementation for suns RI or
> if that also fails we try to lookup container specific implementations
> like tomcats AnnotationProcessor implementation. If all fails we
> supply a default implementation which only handles @PostConstruct and
> @PreDestroy annotations - I don't think that it is possible to inject
> any resource w/o knowing how to lookup these.


This sounds very similar to what Ryan just talked about in his blog.  Bernd,
if are happy w/ this and still interested, feel free to go forward with
this.  If you still want to, I ask that the default implementation uses the
annotation name, rather than the annotation.  This gives Tomcat 5.5/Facelets
users fewer headaches.

Do either of you have a problem w/ the context listener doing a classpath
search for well known injection providers?  I meet a lot of devs who find
JSF too configuration heavy.

Bernd if you don't get around to doing this, I will just end up doing it
sometime next week.

2007/3/3, Bernd Bohmann <be...@atanion.com>:
> > Sorry,
> > I ask you if it's ok to add the code.
> > I get no answer then I asume it's ok to add my idea.
> >
> > It's only a different possible implementation.
> > If you don't like it you can remove it.
> > Is anything wrong with the code?
> >
> > Bernd
> >
> >
> >
> > Dennis Byrne wrote:
> > > 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
> > >> >> >> >
> > >> >> >>
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >>
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > >
> >
>
>
> --
> Mathias
>



-- 
Dennis Byrne

Re: @PreDestroy, Servlet API,

[Mathias Brökelmann <mb...@googlemail.com>]

No code in myfaces (or any other apache project) is owned by someone.
That is important for a healthy and moving community. Bernds
submission was a little bit fast but sometimes a complex issue is
better understand if we can look at the code - no matter if that is
the solution we finally have.

I wasn't aware that tomcat already has something like an
AnnotationProcessor which defines exactly that kind of
InjectionProvider which the RI uses. But it perfectly matches our
requirements.

How about this solution:

We define a myfaces specific interface of an
AnnotationProcessor/InjectionProvider which will be used throughout
the code in myfaces. The initialization code lookups an implementation
for that interface. If there is nothing found (through context param,
META-INF/service, etc.) we implement some fallback strategies to
either looking for a InjectionProvider implementation for suns RI or
if that also fails we try to lookup container specific implementations
like tomcats AnnotationProcessor implementation. If all fails we
supply a default implementation which only handles @PostConstruct and
@PreDestroy annotations - I don't think that it is possible to inject
any resource w/o knowing how to lookup these.


2007/3/3, Bernd Bohmann <be...@atanion.com>:
> Sorry,
> I ask you if it's ok to add the code.
> I get no answer then I asume it's ok to add my idea.
>
> It's only a different possible implementation.
> If you don't like it you can remove it.
> Is anything wrong with the code?
>
> Bernd
>
>
>
> Dennis Byrne wrote:
> > 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >> >
> >>
> >
> >
> >
>


-- 
Mathias

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

Sorry,
I ask you if it's ok to add the code.
I get no answer then I asume it's ok to add my idea.

It's only a different possible implementation.
If you don't like it you can remove it.
Is anything wrong with the code?

Bernd



Dennis Byrne wrote:
> 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

Just revert my commit

Dennis Byrne wrote:
> 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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
>> >> >> >
>> >> >>
>> >> >
>> >> >
>> >> >
>> >>
>> >
>> >
>> >
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <be...@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 <be...@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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

??? 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 <be...@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.2 and
>> > 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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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.2 can
>> >> support
>> >> > > > > > > servlet 2.4 containers?
>> >> > > > > > >
>> >> > > > > > > Best wishes,
>> >> > > > > > > Paul
>> >> > > > > > >
>> >> > > > > > > On 2/26/07, Dennis Byrne <de...@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 <pa...@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
>> >> >
>> >>
>> >
>> >
>> >
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <be...@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.2 and
> > 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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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.2 can
> >> support
> >> > > > > > > servlet 2.4 containers?
> >> > > > > > >
> >> > > > > > > Best wishes,
> >> > > > > > > Paul
> >> > > > > > >
> >> > > > > > > On 2/26/07, Dennis Byrne <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

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.2 and
> 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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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.2 can
>> support
>> > > > > > > servlet 2.4 containers?
>> > > > > > >
>> > > > > > > Best wishes,
>> > > > > > > Paul
>> > > > > > >
>> > > > > > > On 2/26/07, Dennis Byrne <de...@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 <pa...@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
>> >
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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.2 and
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 <pa...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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.2 can
> support
> > > > > > > servlet 2.4 containers?
> > > > > > >
> > > > > > > Best wishes,
> > > > > > > Paul
> > > > > > >
> > > > > > > On 2/26/07, Dennis Byrne <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Paul McMahan <pa...@gmail.com>]

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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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
>

Re: [jira] @PreDestroy, Servlet API,

[djencks <da...@yahoo.com>]

This thread seems to have died down.

I've tried to start a new thread on a related proposal I've come up with
while thinking about how to integrate MyFaces into geronimo, the subject is
"Proposal for annotation processing" and there's a related jira issue
https://issues.apache.org/jira/browse/MYFACES-1559

It's possibly my mail is messed up so I may have to repost the proposal as a
reply to this message.

many thanks
david jencks



Bernd Bohmann wrote:
> 
> What is wrong with
> 
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
> 
> ?
> 
> <big snip>
> 
> 

-- 
View this message in context: http://www.nabble.com/%40PreDestroy%2C-Servlet-API%2C-tf3284592.html#a9437097
Sent from the My Faces - Dev mailing list archive at Nabble.com.

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

What is wrong with

http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java

?



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 <mb...@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 <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

Hello Dennis,

I think the interface has nothing to do with tomcat. Would the interface 
meet your requirements?

If yes, I would suggest following:

Create a AnnotationProcessorFactory which return as default an 
AnnotationProcessor who is a copy of the tomcat 
DefaultAnnotationProcessor(the code has no dependency to other tomcat 
code). I think the factory should return a suitable AnnotationProcessor 
based on which Annotations are present in the classpath.

Maybe we can make the AnnotationProcessor configurable.

If you like I would add this code to 1.2.

Regards

Bernd

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

On 3/3/07, Bernd Bohmann <be...@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 <mb...@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 <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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

Re: @PreDestroy, Servlet API,

[Bernd Bohmann <be...@atanion.com>]

Hello Dennis,

why we should look at the RI?

Can we use this Interface

http://tomcat.apache.org/tomcat-6.0-doc/api/org/apache/AnnotationProcessor.html?

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.

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 <mb...@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 <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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
>>
> 
> 
> 

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <mb...@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 <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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

Re: @PreDestroy, Servlet API,

[Mathias Brökelmann <mb...@googlemail.com>]

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 <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@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 <mb...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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.2 can
> support
> > > > > > servlet 2.4 containers?
> > > > > >
> > > > > > Best wishes,
> > > > > > Paul
> > > > > >
> > > > > > On 2/26/07, Dennis Byrne <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Mathias Brökelmann <mb...@googlemail.com>]

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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Paul McMahan <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <pa...@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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Paul McMahan <pa...@gmail.com>]

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 <de...@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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <pa...@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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Paul McMahan <pa...@gmail.com>]

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 <de...@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 <pa...@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

Re: @PreDestroy, Servlet API,

[Dennis Byrne <de...@dbyrne.net>]

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 <pa...@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 <de...@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

Re: @PreDestroy, Servlet API,

[Paul McMahan <pa...@gmail.com>]

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