geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul McMahan" <>
Subject Re: Generic way to handle annotations for integrating projects
Date Wed, 07 Mar 2007 15:53:21 GMT
Due to my own limited knowledge of xbean and the nuances of deployment
I can't claim to totally understand all the benefits of allowing the
application server to handle instantiation for objects annotated for
dependency injection.   I have a hunch that the main benefit is that
it allows the container to pick which constructor it uses and even in
some cases call various application server specific lifecycle methods
on the object.  If that's true then I can see a tremendous benefit
if/when Geronimo extends annotation support outward towards GBeans.
Are there other benefits that should be pointed out as well?

I think that most integrating projects would support this approach.
In fact when I asked the MyFaces team about dependency injection their
initial response was something along the lines of -- why can't the
container intercept object instantiation and handle injection at the
classloader level?  (but that's not, BTW, how MyFaces finally ended up
providing injection support).  However, when discussing that approach
they were reluctant to relinquish control of @PostConstruct and
@PreDestroy because there is explicit language in the JSF spec about
how those annotations relate to the scope and lifecycle of managed
beans.  So, playing the MyFaces advocate here, how would their
component be assured of spec compliance when running in a container
that doesn't necessarily support this new approach?

Something else to take into consideration, at least for MyFaces, is
that their current approach is mostly compatible with how the JSF RI
and Tomcat provide injection support, which makes it easier to replace
the JSF RI with MyFaces in Glassfish and other application server
environments. In order for MyFaces to implement behavior that is much
different than the RI I think they would need to see much stronger
language in the JSF spec around dependency injection.  So it might be
worthwhile to pursue this as an addendum to the JSF and perhaps even
the JEE specs.

Best wishes,

On 3/6/07, David Jencks <> wrote:
> I've been working on annotation handling for jetty using xbean-
> reflect and have come up with a design for general annotation
> processing that I would like to propose we urge our integrated
> projects to allow or adopt.
> This is appropriate when the injection only involves stuff looked up
> in jndi and when the sequence of events is
> - construct instance
> - inject stuff
> - call postConstruct
> with no intervening container lifecycle calls.
> So I'd like each project to define an interface
> public interface <Project>LifecycleSupport {
> Object newInstance(String className); //might need a classloader too
> depending on whether the project has per-module instances
> void destroyInstance(Object o);
> }
> and provide a way we can inject such an object into the projects
> framework.
> We can then implement the newInstance method to construct and inject
> properties using xbean-reflect and call postConstruct, and
> destroyInstance to call preDestroy.
> Another style has been popularized by tomcat (?) which has 3 methods
> inject(Object)
> postConstruct(Object)
> preDestroy(Object)
> We can use this style but then we wont be able to use xbean-reflect
> which hides all the hard part :-) and would let us go beyond the spec
> and support constructor injection if we can figure out how to get
> constructor metadata to it.
> It's pretty trivial to implement an adapter between my proposal and
> the tomcat style, but not vice versa.
> So, where would this be used?  The most likely bits are MyFaces, CXF,
> and Axis2.  I'm already doing something very similar for jetty and
> haven't looked to see if tomcat can be adapted this way.
> Thoughts?
> thanks
> david jencks

View raw message