geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject Re: [xbean] annotation based dependency injection
Date Mon, 03 Apr 2006 12:12:10 GMT
On 4/3/06, Jacek Laskowski <> wrote:
> On 4/3/06, James Strachan <> wrote:
> > I just blogged about this
> >
> >
> > but I thought I'd mention it here...
> >
> Thanks James for sharing it with us! I'm reading EJB 3.0 spec and...
> > EJB 3 pretty much mandates a similar model;
> 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.



View raw message