Generic way to handle annotations for integrating projects

[David Jencks <da...@yahoo.com>]

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

Re: Generic way to handle annotations for integrating projects

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

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 <da...@yahoo.com> 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
>
>

Re: Generic way to handle annotations for integrating projects

[David Jencks <da...@yahoo.com>]

On Mar 7, 2007, at 2:46 AM, Lasantha Ranaweera wrote:

> David,
>
> May be a silly question. How about handling JPA  related annotations?

I can think of 2 kinds of jpa related annotations.  There are  
PersistenceManagerRef and PersistenceUnitRef which are injection  
related and that we already handle with our NamingBuilder framework,  
and there are annotations on the entities to help make them  
persistence capable, which the jpa framework we use deals with  
without any help from us: informing the jpa framework about these is  
done by the PersistenceUnitBuilder.  As far as I know an entity  
managed by jpa cannot have injections which would be the situation  
relevant to this proposal.  Does this make sense?

thanks
david jencks


>
> Thanks,
> Lasantha
> 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
>>
>>
>
>

Re: Generic way to handle annotations for integrating projects

[Lasantha Ranaweera <la...@opensource.lk>]

David,

May be a silly question. How about handling JPA  related annotations?

Thanks,
Lasantha
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
>
>