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,
Paul
On 3/6/07, David Jencks <[EMAIL PROTECTED]> 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
