You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by James Strachan <ja...@gmail.com> on 2006/04/03 11:24:04 UTC
[xbean] annotation based dependency injection
I just blogged about this
http://radio.weblogs.com/0112098/2006/04/03.html#a557
but I thought I'd mention it here...
http://docs.codehaus.org/display/XB/Annotation+based+Dependency+Injection
EJB 3 pretty much mandates a similar model; so I'm sure the XBean/OpenEJB
folks will be implementing this anyway. I'm also interested in seeing how
JAXB 2 could be used as a possible bi-directional XML marshalling layer for
this DI model.
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by James Strachan <ja...@gmail.com>.
On 4/5/06, David Blevins <da...@visi.com> wrote:
>
> On Apr 5, 2006, at 2:30 AM, James Strachan wrote:
>
> > On 4/5/06, David Blevins <da...@visi.com> wrote:
> >> On Apr 4, 2006, at 11:37 PM, James Strachan wrote:
> >>
> >>> On 4/4/06, David Blevins <da...@visi.com> wrote:
> >>>>
> >>> Good point - though before JSR 250 & EJB 3, when Pico was just
> >>> starting, I tended to use the convention that contructor arguments
> >>> were 'mandatory' properties and setter methods were for optional
> >>> stuff
> >>> (or stuff that can be configured after construction).
> >>>
> >>> i.e. its kinda implicit that any constructor arguments must be
> >>> injected to be able to construct the object - so they are mandatory
> >>> already. I guess a container could shove in null objects or zero
> >>> values if it can't find a value, but maybe its easier to just say
> >>> that
> >>> for constructor injection, the parameters should be considered
> >>> mandatory?
> >>
> >> I get it -- you're using @Resource to imply whether or not an object
> >> attribute is optional or required.
> >
> > Yeah; Ideally there would be an @Mandatory in JSR 250 on properties...
> >
> >> We're talking about different
> >> things then. Was more going after EJB 3 perspective where @Resource
> >> is primarily used to label an object attribute with an identifier and
> >> optional mapping the injector understands (such as a jndi name, an
> >> xml attribute or element name, or whatever).
> >
> > Yeah. Though the EJB 3 injection is more like auto-JNDI lookup; the
> > POJO is kinda pulling resources into itself using the name it defines.
> > In Spring style, the XML config injects into the POJO without its
> > particular pre-knowledge. So AnDI is a little attempt to reclaim the
> > @Resource annotation for non-JNDI style injection where we can just
> > use it as a marker for what are the mandatory properties.
>
> Exactly. Lot's of stuff could fall under the "whatever" category...
> kernel references or just about anything could be named via @Resource
> (name="foo"). Heck, if you use a URI in there like I know you would,
> you could do anything with it :) I'd be likely to endorse something
> sick and twisted like that ;)
LOL. I've gone a bit URI crazy lately - they're the crack of strings;
quite addictive :) I blame hiram for getting me hooked :)
> >> Seems like in your scenario, someone couldn't use the annotation to
> >> specify how object attribute would be populated via an injectable
> >> resource but still let it be an optional dependency. Guessing you
> >> don't really care though :)
> >
> > This is a good point. I'd assumed in EJB 3 land that @Resource implies
> > mandatory injection; what happens if there is no value available in
> > JNDI? Is that an error or is null used? If its the latter then maybe
> > we do need a @Mandatory or @NotNull or something.
>
> Right, EJB 3 says they are mandatory. But thinking along your lines
> of slightly repurposing it for better use, you could theoretically
> allow someone to label an object attribute via @Resource and still
> annotate or flag it as optional somehow. Just a thought.
Yeah; I guess the only downside is it'd involve changing semantics;
the presence of @Resource currently implies mandatory injection, so
maybe we should add a new annotation for optional properties?
@OptionalResource?
I have been musing lately about creating a little library of common
annotations we can share across projects - kinda like JSR 250
extensions. Care should be taken to avoid them getting too out of
control or loosing their meaning but there's a few on the wiki now...
http://docs.codehaus.org/display/XB/Other+Annotations
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by David Blevins <da...@visi.com>.
On Apr 5, 2006, at 2:30 AM, James Strachan wrote:
> On 4/5/06, David Blevins <da...@visi.com> wrote:
>> On Apr 4, 2006, at 11:37 PM, James Strachan wrote:
>>
>>> On 4/4/06, David Blevins <da...@visi.com> wrote:
>>>>
>>> Good point - though before JSR 250 & EJB 3, when Pico was just
>>> starting, I tended to use the convention that contructor arguments
>>> were 'mandatory' properties and setter methods were for optional
>>> stuff
>>> (or stuff that can be configured after construction).
>>>
>>> i.e. its kinda implicit that any constructor arguments must be
>>> injected to be able to construct the object - so they are mandatory
>>> already. I guess a container could shove in null objects or zero
>>> values if it can't find a value, but maybe its easier to just say
>>> that
>>> for constructor injection, the parameters should be considered
>>> mandatory?
>>
>> I get it -- you're using @Resource to imply whether or not an object
>> attribute is optional or required.
>
> Yeah; Ideally there would be an @Mandatory in JSR 250 on properties...
>
>> We're talking about different
>> things then. Was more going after EJB 3 perspective where @Resource
>> is primarily used to label an object attribute with an identifier and
>> optional mapping the injector understands (such as a jndi name, an
>> xml attribute or element name, or whatever).
>
> Yeah. Though the EJB 3 injection is more like auto-JNDI lookup; the
> POJO is kinda pulling resources into itself using the name it defines.
> In Spring style, the XML config injects into the POJO without its
> particular pre-knowledge. So AnDI is a little attempt to reclaim the
> @Resource annotation for non-JNDI style injection where we can just
> use it as a marker for what are the mandatory properties.
Exactly. Lot's of stuff could fall under the "whatever" category...
kernel references or just about anything could be named via @Resource
(name="foo"). Heck, if you use a URI in there like I know you would,
you could do anything with it :) I'd be likely to endorse something
sick and twisted like that ;)
>> Seems like in your scenario, someone couldn't use the annotation to
>> specify how object attribute would be populated via an injectable
>> resource but still let it be an optional dependency. Guessing you
>> don't really care though :)
>
> This is a good point. I'd assumed in EJB 3 land that @Resource implies
> mandatory injection; what happens if there is no value available in
> JNDI? Is that an error or is null used? If its the latter then maybe
> we do need a @Mandatory or @NotNull or something.
Right, EJB 3 says they are mandatory. But thinking along your lines
of slightly repurposing it for better use, you could theoretically
allow someone to label an object attribute via @Resource and still
annotate or flag it as optional somehow. Just a thought.
-David
Re: [xbean] annotation based dependency injection
Posted by James Strachan <ja...@gmail.com>.
On 4/5/06, David Blevins <da...@visi.com> wrote:
> On Apr 4, 2006, at 11:37 PM, James Strachan wrote:
>
> > On 4/4/06, David Blevins <da...@visi.com> wrote:
> >>
> >> On Apr 3, 2006, at 5:12 AM, James Strachan wrote:
> >>
> >>>> so I'm sure the XBean/OpenEJB folks will be implementing this
> >>> anyway.
> >>>
> >>> I'm not yet at that point in understanding what Dave B. has already
> >>> done in OpenEJB 3, but you're right it will be of high priority to
> >>> implement.
> >>>
> >>> Agreed. Adding support for AnDI into XBean would be pretty easy
> >>> then OpenEJB could reuse that. I ultimately want the entire
> >>> Geronimo kernel to support AnDI; whether you use EJB3 or not.
> >>
> >> Trick is the @Resource annotation can't be used to annotate a
> >> constructor.
> >>
> >> Know anyone on JSR 250 who'd propose changing that?
> >
> > Good point - though before JSR 250 & EJB 3, when Pico was just
> > starting, I tended to use the convention that contructor arguments
> > were 'mandatory' properties and setter methods were for optional stuff
> > (or stuff that can be configured after construction).
> >
> > i.e. its kinda implicit that any constructor arguments must be
> > injected to be able to construct the object - so they are mandatory
> > already. I guess a container could shove in null objects or zero
> > values if it can't find a value, but maybe its easier to just say that
> > for constructor injection, the parameters should be considered
> > mandatory?
>
> I get it -- you're using @Resource to imply whether or not an object
> attribute is optional or required.
Yeah; Ideally there would be an @Mandatory in JSR 250 on properties...
> We're talking about different
> things then. Was more going after EJB 3 perspective where @Resource
> is primarily used to label an object attribute with an identifier and
> optional mapping the injector understands (such as a jndi name, an
> xml attribute or element name, or whatever).
Yeah. Though the EJB 3 injection is more like auto-JNDI lookup; the
POJO is kinda pulling resources into itself using the name it defines.
In Spring style, the XML config injects into the POJO without its
particular pre-knowledge. So AnDI is a little attempt to reclaim the
@Resource annotation for non-JNDI style injection where we can just
use it as a marker for what are the mandatory properties.
Incidentally if you are considering mapping of properties to XML; then
the JAXB 2 annotations are way more flexible and have better
semantics. e.g. @XmlAttribute, @XmlElement - along with all the
namespace stuff together with things like @XmlID, @XmlIDRef and a ton
of other stuff.
> Seems like in your scenario, someone couldn't use the annotation to
> specify how object attribute would be populated via an injectable
> resource but still let it be an optional dependency. Guessing you
> don't really care though :)
This is a good point. I'd assumed in EJB 3 land that @Resource implies
mandatory injection; what happens if there is no value available in
JNDI? Is that an error or is null used? If its the latter then maybe
we do need a @Mandatory or @NotNull or something.
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by David Blevins <da...@visi.com>.
On Apr 4, 2006, at 11:37 PM, James Strachan wrote:
> On 4/4/06, David Blevins <da...@visi.com> wrote:
>>
>> On Apr 3, 2006, at 5:12 AM, James Strachan wrote:
>>
>>>> so I'm sure the XBean/OpenEJB folks will be implementing this
>>> anyway.
>>>
>>> I'm not yet at that point in understanding what Dave B. has already
>>> done in OpenEJB 3, but you're right it will be of high priority to
>>> implement.
>>>
>>> Agreed. Adding support for AnDI into XBean would be pretty easy
>>> then OpenEJB could reuse that. I ultimately want the entire
>>> Geronimo kernel to support AnDI; whether you use EJB3 or not.
>>
>> Trick is the @Resource annotation can't be used to annotate a
>> constructor.
>>
>> Know anyone on JSR 250 who'd propose changing that?
>
> Good point - though before JSR 250 & EJB 3, when Pico was just
> starting, I tended to use the convention that contructor arguments
> were 'mandatory' properties and setter methods were for optional stuff
> (or stuff that can be configured after construction).
>
> i.e. its kinda implicit that any constructor arguments must be
> injected to be able to construct the object - so they are mandatory
> already. I guess a container could shove in null objects or zero
> values if it can't find a value, but maybe its easier to just say that
> for constructor injection, the parameters should be considered
> mandatory?
I get it -- you're using @Resource to imply whether or not an object
attribute is optional or required. We're talking about different
things then. Was more going after EJB 3 perspective where @Resource
is primarily used to label an object attribute with an identifier and
optional mapping the injector understands (such as a jndi name, an
xml attribute or element name, or whatever).
Seems like in your scenario, someone couldn't use the annotation to
specify how object attribute would be populated via an injectable
resource but still let it be an optional dependency. Guessing you
don't really care though :)
-David
Re: [xbean] annotation based dependency injection
Posted by James Strachan <ja...@gmail.com>.
BTW I think JSR 250 is kinda frozen now (despite not being final);
though I'm hoping if we all get behind it and use it as the basis of
AnDI we can get another minor update done later on - e.g. to remove
the restriction on no checked exceptions on @PostConstruct/@PreDestroy
methods. etc.
James
On 4/5/06, James Strachan <ja...@gmail.com> wrote:
> On 4/4/06, David Blevins <da...@visi.com> wrote:
> >
> > On Apr 3, 2006, at 5:12 AM, James Strachan wrote:
> >
> > > > so I'm sure the XBean/OpenEJB folks will be implementing this
> > > anyway.
> > >
> > > I'm not yet at that point in understanding what Dave B. has already
> > > done in OpenEJB 3, but you're right it will be of high priority to
> > > implement.
> > >
> > > Agreed. Adding support for AnDI into XBean would be pretty easy
> > > then OpenEJB could reuse that. I ultimately want the entire
> > > Geronimo kernel to support AnDI; whether you use EJB3 or not.
> >
> > Trick is the @Resource annotation can't be used to annotate a
> > constructor.
> >
> > Know anyone on JSR 250 who'd propose changing that?
>
> Good point - though before JSR 250 & EJB 3, when Pico was just
> starting, I tended to use the convention that contructor arguments
> were 'mandatory' properties and setter methods were for optional stuff
> (or stuff that can be configured after construction).
>
> i.e. its kinda implicit that any constructor arguments must be
> injected to be able to construct the object - so they are mandatory
> already. I guess a container could shove in null objects or zero
> values if it can't find a value, but maybe its easier to just say that
> for constructor injection, the parameters should be considered
> mandatory?
> --
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by James Strachan <ja...@gmail.com>.
On 4/4/06, David Blevins <da...@visi.com> wrote:
>
> On Apr 3, 2006, at 5:12 AM, James Strachan wrote:
>
> > > so I'm sure the XBean/OpenEJB folks will be implementing this
> > anyway.
> >
> > I'm not yet at that point in understanding what Dave B. has already
> > done in OpenEJB 3, but you're right it will be of high priority to
> > implement.
> >
> > Agreed. Adding support for AnDI into XBean would be pretty easy
> > then OpenEJB could reuse that. I ultimately want the entire
> > Geronimo kernel to support AnDI; whether you use EJB3 or not.
>
> Trick is the @Resource annotation can't be used to annotate a
> constructor.
>
> Know anyone on JSR 250 who'd propose changing that?
Good point - though before JSR 250 & EJB 3, when Pico was just
starting, I tended to use the convention that contructor arguments
were 'mandatory' properties and setter methods were for optional stuff
(or stuff that can be configured after construction).
i.e. its kinda implicit that any constructor arguments must be
injected to be able to construct the object - so they are mandatory
already. I guess a container could shove in null objects or zero
values if it can't find a value, but maybe its easier to just say that
for constructor injection, the parameters should be considered
mandatory?
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by David Blevins <da...@visi.com>.
On Apr 3, 2006, at 5:12 AM, James Strachan wrote:
> > so I'm sure the XBean/OpenEJB folks will be implementing this
> anyway.
>
> I'm not yet at that point in understanding what Dave B. has already
> done in OpenEJB 3, but you're right it will be of high priority to
> implement.
>
> Agreed. Adding support for AnDI into XBean would be pretty easy
> then OpenEJB could reuse that. I ultimately want the entire
> Geronimo kernel to support AnDI; whether you use EJB3 or not.
Trick is the @Resource annotation can't be used to annotate a
constructor.
Know anyone on JSR 250 who'd propose changing that?
-David
Re: [xbean] annotation based dependency injection
Posted by James Strachan <ja...@gmail.com>.
On 4/3/06, Jacek Laskowski <ja...@laskowski.net.pl> wrote:
>
> On 4/3/06, James Strachan <ja...@gmail.com> wrote:
> > I just blogged about this
> > http://radio.weblogs.com/0112098/2006/04/03.html#a557
> >
> > but I thought I'd mention it here...
> > http://docs.codehaus.org/display/XB/Annotation+based+Dependency+Injection
>
>
> Thanks James for sharing it with us! I'm reading EJB 3.0 spec and...
>
> > EJB 3 pretty much mandates a similar model;
>
> ...am wondering if I have already missed something as EJB 3.0 is
> exactly about it rather than 'pretty much' that.
I do suggest diverging a little from JSR 250 though; e.g. checked exceptions
on lifecycle methods - and maybe an alternative interpretation of @Resource
when using Spring
Unless I'm mistaken,
> I think you might think that the annotations might not fit EJB 3.0
> yet. Is it that?
No not really. EJB reuses the annotations defined in JSR 250 for session
beans. However DI is way more useful across the board than just for making
Session beans. FWIW it was the Spring & Pico communities who brought DI to
the mainstream; the only downside is they currently implement lifecycles
using interfaces. Now we have JSR 250 we have a chance to unify EJB, Spring,
Pico and SCA to use the same DI contract.
My motivation here wasn't to particularly claim anything new; it was to try
and unify the communities so that if you are a POJO developer you should
have one DI contract to think about - AnDI - which has nothing to do with
EJB 3 per se (to avoid politics such as EJB3 v SCA or JBoss v Spring and so
forth) and can be used on any POJO whether you use SCA, EJB3 or not.
So in realitly its mostly just JSR 250 really - but the paper talks about
how we should deal with migration from Spring/Pico lifecycles to AnDI
together with highlighting some issues of JSR 250. (e.g. I'd like to
encourage a spec change among implementors by allowing @PostConstruct and
@PreDestroy to throw checked exceptions).
Anyway, you're right that we've got lots of IoC containers and they
> *do* tend to work behind the scenes, but they fail short wrt their
> annotations that polute a code. I wish I could see a pojo that's
> expected to run in two or more IoC containers. The code would surely
> look horribly and its maintenance would very likely result in lots of
> pain, wouldn't it?
Agreed. Though as I mentioned on the wiki page; its pretty easy to, say,
make any Spring or Pico POJO support AnDI by just annotating the lifecycle
interfaces these frameworks use.
It seems that with all those IoC containers the only missing piece in
> the puzzle is to lay a common ground for them, e.g. as a JSR.
Yeah. Though technically we have JSR 250 now :) though folks have never
really championed using JSR 250 as a DI standard up to now. (Its often only
EJB 3 folks who've spotted it :). I guess I'm trying to repurpose JSR 250 as
the AnDI JSR; a standard DI contract using annotations and try to unify the
POJO developer communities.
> so I'm sure the XBean/OpenEJB folks will be implementing this anyway.
>
> I'm not yet at that point in understanding what Dave B. has already
> done in OpenEJB 3, but you're right it will be of high priority to
> implement.
Agreed. Adding support for AnDI into XBean would be pretty easy then OpenEJB
could reuse that. I ultimately want the entire Geronimo kernel to support
AnDI; whether you use EJB3 or not.
--
James
-------
http://radio.weblogs.com/0112098/
Re: [xbean] annotation based dependency injection
Posted by Jacek Laskowski <ja...@laskowski.net.pl>.
On 4/3/06, James Strachan <ja...@gmail.com> wrote:
> I just blogged about this
> http://radio.weblogs.com/0112098/2006/04/03.html#a557
>
> but I thought I'd mention it here...
> http://docs.codehaus.org/display/XB/Annotation+based+Dependency+Injection
Thanks James for sharing it with us! I'm reading EJB 3.0 spec and...
> EJB 3 pretty much mandates a similar model;
...am wondering if I have already missed something as EJB 3.0 is
exactly about it rather than 'pretty much' that. Unless I'm mistaken,
I think you might think that the annotations might not fit EJB 3.0
yet. Is it that?
Anyway, you're right that we've got lots of IoC containers and they
*do* tend to work behind the scenes, but they fail short wrt their
annotations that polute a code. I wish I could see a pojo that's
expected to run in two or more IoC containers. The code would surely
look horribly and its maintenance would very likely result in lots of
pain, wouldn't it?
It seems that with all those IoC containers the only missing piece in
the puzzle is to lay a common ground for them, e.g. as a JSR.
> so I'm sure the XBean/OpenEJB folks will be implementing this anyway.
I'm not yet at that point in understanding what Dave B. has already
done in OpenEJB 3, but you're right it will be of high priority to
implement.
Thanks!
> James
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl