myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis Byrne" <den...@dbyrne.net>
Subject Re: @PreDestroy, Servlet API,
Date Fri, 02 Mar 2007 21:06:52 GMT
Similar to what Mathias mentioned?

http://issues.apache.org/jira/browse/MYFACES-1246#action_12475337

It's not much work (on our side) but it sounds pretty vendor specific.
Again, I don't have a better solution.  Mathias writes "which is implemented
by j2ee containers".  I wonder if each container will end up looking for
different interfaces.  How would MyFaces find Geronimo's implementation ?  A
context parameter?  A for loop like this ...

String[] providers = new String[]{"org,apache.geronimo.DIProvider", "
com.bea.DIProvider", "org.jboss.DIProvider"}

for(String clazz : providers){
  try{
    return ClassUtils.load(clazz)
  }catch(){}
}

Dennis Byrne

On 3/1/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
>
> OK, I think your interpretation of the spec makes sense and there's
> one particular aspect we should discuss a little further.
>
> The container doesn't know which classes are managed beans so it
> wouldn't know when to intercept the instantiation process to perform
> injection.  What would you all think about MyFaces providing an
> interface that containers could implement to perform injection on a
> managed bean when MyFaces brings that bean into service?  This would
> allow MyFaces to maintain control of the timing while allowing the
> container to scan for annotations and handle injection when prompted
> to do so.
>
> Best wishes,
> Paul
>
>
> On 2/26/07, Dennis Byrne <dennis@dbyrne.net> wrote:
> > I know the specs can be vague sometimes, but I don't interpret the first
> > paragraph of section 5.4 as meaning the JSF implementation is
> responsible
> > for @EJB, @Resources, etc.  The JSF spec specifically mentions "the
> > container to inject references".  If Geronimo can intercept the
> > instantiation of these classes in the classloader (something I know
> nothing
> > about right now), I think we are all good here.  Wouldn't MyFaces then
> be
> > observing the requirements (in plain java) around @PostConstruct after
> > Geronimo had injected the resources?
> >
> > I think the JSF impl is only responsible for @PostConstruct and
> @Predestroy.
> >  This makes sense because scoped (request, session, application) are the
> > only candidates for this, and it would be more awkward to do that from
> the
> > container. I say all of this in an open manner, so anyone feel free to
> > discuss.
> >
> > You're point about javax.annotation being in the Servlet 2.5 is
> taken.  I
> > totally missed that.
> >
> >
> > Dennis Byrne
> >
> > On 2/26/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> > > Actually by "dependency injection" I'm specifically referring to the
> > > portion of the JSF spec that discusses injecting resources where
> > > certain annotations are found in a managed bean.  So, while scanning
> > > for the @PreConstruct and @PostDestroy annotations MyFaces would also
> > > scan for @EJB, @Resource, @WebServiceRef, etc and then time the
> > > invocation of @PreConstruct and @PostDestroy to support the injection.
> > >
> > > Tomcat provides an example of how this can be done.  The following
> > > class scans for annotations when a web app starts:
> > >
> >
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/startup/WebAnnotationSet.java
> > >
> > > And then this class handles the injection and calling the
> > > PostConstruct and PreDestroy methods when an servlet, filter, or
> > > listener is brought into service:
> > >
> >
> http://svn.apache.org/repos/asf/tomcat/tc6.0.x/trunk/java/org/apache/catalina/util/DefaultAnnotationProcessor.java
> > >
> > > Would it make sense for MyFaces to follow a similar approach for
> > > managed beans?  Also, I'm curious why you're hoping to avoid importing
> > > classes from javax.annotation classes since servlet 2.5 containers are
> > > required to support them.  Is this so that MyFaces 1.2 can support
> > > servlet 2.4 containers?
> > >
> > > Best wishes,
> > > Paul
> > >
> > > On 2/26/07, Dennis Byrne <dennis@dbyrne.net> wrote:
> > > > I ended up going with Servlet/Request/Context attribute listeners
> for
> > > > @PreDestroy.  This did not involve importing
> > javax.annotation.PreDestroy, so
> > > > people w/out application servers don't have to worry about
> > > > ClassDefNotFoundErrors.  This also keeps us compatible with the
> > reference
> > > > implementation in terms of timing, although I really wish they'd
> change
> > the
> > > > wording in the spec.
> > > >
> > > > Dennis Byrne
> > > >
> > > >
> > > > On 2/26/07, Paul McMahan <paulmcmahan@gmail.com> wrote:
> > > > > Sorry if I'm behind on this discussion but what are the current
> > > > > thoughts on how dependency injection will be implemented for
> managed
> > > > > beans?  The reason I'm curious is because PreDestroy and
> PostConstruct
> > > > > annotations are used to deal with injected resources, so from a
> timing
> > > > > perspective it would be important to process all these annotations
> > > > > accordingly.
> > > > >
> > > > > Best wishes,
> > > > > Paul
> > > > >
> > > > > On 2/24/07, Dennis Byrne < dennis@dbyrne.net> wrote:
> > > > > > I'm weighing options about invoking @PreDestroy methods
> > (@PostConstruct
> > > > is
> > > > > > done BTW).  I haven't made up my mind yet but here's where I'm
> at on
> > > > this.
> > > > > >
> > > > > > As far as *when* this happens, the request is easy, in
> > > > > > FacesServelet.service(). Session and app scope are more
> difficult
> > > > decisions.
> > > > > > A new
> > HttpSessionActivationListener.attributeRemoved
> > > > and a
> > > > > > new
> > ServletContextAttributeListener.attributeRemoved ()
> > > > seem
> > > > > > like nice solutions, but this doesn't meet the spec requirements
> for
> > > > 5.4.1.
> > > > > > The methods have to be invoked *before* the bean is pulled from
> > scope
> > > > and
> > > > > > the servlet API does not provide a
> > > > > >
> > > >
> > ServletContextAttributeListener.attribute_WILL_BE_Removed()
> > > > > > or a
> > > > > >
> > HttpSessionActivationListener.attribute_WILL_BE_Removed
> > > > ().
> > > > > >  Also, I say *new* ServletContextAttributeListener and because
> > > > > > StartupServletContextListener (already in code base) implements
> > > > > > ServletContextListener, not
> > > > > > ServletContextAttributeListener.
> > > > > >
> > > > > > The other side of the problem is *how* to invoke each
> @PreDestroy
> > > > method,
> > > > > > much easier.  Iterating over the attributes at each scope level
> is
> > > > trivial,
> > > > > > and so is determining if the bean's class is a managed bean
> class.
> > But
> > > > this
> > > > > > does not mean the *instance* was placed there by the JSF
> > implementation.
> > > > > > Using a list (at each level of scope) to track managed instances
> > solves
> > > > the
> > > > > > problem, as long as you sync on the session (only one time per
> > session)
> > > > in
> > > > > > order to avoid concurrency issues; it also means three more
data
> > > > structures
> > > > > > in memory.
> > > > > >
> > > > > > --
> > > > > > Dennis Byrne
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Dennis Byrne
> > >
> >
> >
> >
> > --
> > Dennis Byrne
>



-- 
Dennis Byrne

Mime
View raw message