Annotations - call for proposals

[Danny Angus <da...@gmail.com>]

Hi,

During the discussions provoked by the experiment on using JNDI for
Mailet service lookup in the sandbox the subject of annotations came
up.

I have no strong opinion or vision here, but perhaps someone who was
in favour of annotations would like to kick off a discussion of the
why and how and the merits/demerits of proposing the use of
annotations in the API spec in this thread....

(go on you know you want to..)

d.

Re: Annotations - call for proposals

[Joachim Draeger <jd...@joachim-draeger.de>]

Am Donnerstag, den 04.01.2007, 10:57 +0000 schrieb Danny Angus:

> I have no strong opinion or vision here, but perhaps someone who was
> in favour of annotations would like to kick off a discussion of the
> why and how and the merits/demerits of proposing the use of
> annotations in the API spec in this thread....

I would say, 

Re: Annotations - call for proposals

[Danny Angus <da...@gmail.com>]

On 1/4/07, Stefano Bagnara <ap...@bago.org> wrote:
> I like annotation based dependency injection ala EJB3. Unfortunately
> I've not wrote yet any annotation based container, so I'm not an
> "expert" in this (I only developed applications based on EJB3 and other
> annotation based environments)

No I'm no expert yet either, but if this gets support from you guys I
guess I'll have to learn quick ;-)

> I think this is the best option for a 2007 api. It require java 5, but
> we know that java 2 1.4 we'll be probably declared unsupported soon and
> java 6 is already out, so I think this is not a big deal.

I'd agree up to a point, the new API would not be compatible with Java
1.x but James could continue to support the old API version for as
long as we want.

>
> I would like to see also other Java 5 improvements for a new API:
> generics, enums, varargs.

Well I agree that there are nice features, but I'd rather see what the
problems are before we choose solutions, and it may turn out that
they're more appropriate for container implementors than for the API
spec itself.

d.

Re: Annotations - call for proposals

[Stefano Bagnara <ap...@bago.org>]

I like annotation based dependency injection ala EJB3. Unfortunately 
I've not wrote yet any annotation based container, so I'm not an 
"expert" in this (I only developed applications based on EJB3 and other 
annotation based environments)

I think this is the best option for a 2007 api. It require java 5, but 
we know that java 2 1.4 we'll be probably declared unsupported soon and 
java 6 is already out, so I think this is not a big deal.

I would like to see also other Java 5 improvements for a new API: 
generics, enums, varargs.

Stefano

Danny Angus wrote:
> Hi,
> 
> During the discussions provoked by the experiment on using JNDI for
> Mailet service lookup in the sandbox the subject of annotations came
> up.
> 
> I have no strong opinion or vision here, but perhaps someone who was
> in favour of annotations would like to kick off a discussion of the
> why and how and the merits/demerits of proposing the use of
> annotations in the API spec in this thread....
> 
> (go on you know you want to..)
> 
> d.

Re: Annotations - call for proposals

[Danny Angus <da...@gmail.com>]

On 1/8/07, Joachim Draeger <jd...@joachim-draeger.de> wrote:

> We could try both, annotations and XML descriptor, and postpone the decision. I don't
> consider it as a blocker for further mailet API development.

Of course one alternative would be to process the annotations into an
xml file for a "1.4" compatible version.

d.

Re: Annotations - call for proposals

[Joachim Draeger <jd...@joachim-draeger.de>]

Am Donnerstag, den 04.01.2007, 10:57 +0000 schrieb Danny Angus:

> I have no strong opinion or vision here, but perhaps someone who was
> in favour of annotations would like to kick off a discussion of the
> why and how and the merits/demerits of proposing the use of
> annotations in the API spec in this thread....

I'm not an annotations expert either. :-)

I would say, annotations are only a tool for setter based DI. The first
goal is the user should be able to declare all the dependencies by
hand. It should be possible to provide Mailet 1 and 2 for instance with
two different UserRepositories.
Annotations can do IMO two things: 1. Mark a setter as required 2. provide a hint what is required.

class MyMailet {

@Required
@Servie("userRepository")
setUserRepository(UserRepository userRepository)
}

Now it's the containers turn, what to do with it. The Mailet API itself
can only give a contract (setter based DI) and an advice (e.g.
annotations).

In Spring this should be easy to implement using a BeanPostProcessor.

I'm still unsure whether we should switch James to 1.5. As a software
developer I would say *YES*. :-) And I think our users would benefit
from better code. I don't think that missing JRE for seldom platforms
are an argument. They are so few and switching to another machine
should be possible. The only reasonable argument I'm aware of is J2EE
1.4. Most servers are only certified for JRE 1.4 and that could be an
issue for an API.

Even if we specify the use of annotations for mailet dependencies, Java
1.5 would not be forced. Mailets could still be written for Java 1.4
using another method for dependencies, like wiring by hand.
(This would require compiling the API for 1.4 without the (2) annotations)

I don't consider declaring interfaces like UserRepositoryAware as a
good alternative because there may be too many dependencies.

Wiring dependencies by hand is okay for me. It is a bit work, mostly
copy & paste, search & replace, but gives a good oversight. Inheritance
for similar Mailets like in Spring would make it even easier. 

Specifying XML deployment descriptor is another alternative that is
possible for 1.4. This could contain even more meta-data than
annotations, but we have to take care that it doesn't become too
complex. We could deliver an utility class, that makes reading the
descriptor convenient for container foo.

Conclusion:

I'm convinced that setter based DI is the best way. I'm not sure
whether annotations or a XML descriptor are better. The container (James)
should at least support wiring the deps by hand, like in Spring. (I'm
curious if it's possible to run Spring inside phoenix) 
We could try both, annotations and XML descriptor, and postpone the decision. I don't
consider it as a blocker for further mailet API development.

Joachim


P.S.: sorry again, for premature send. ;-)

Re: Annotations - call for proposals

[Norman Maurer <nm...@byteaction.de>]

Joachim Draeger schrieb:

<snip>
> I'm still unsure whether we should switch James to 1.5. As a software
> developer I would say *YES*. :-) And I think our users would benefit
> from better code. I don't think that missing JRE for seldom platforms
> are an argument. They are so few and switching to another machine
> should be possible. The only reasonable argument I'm aware of is J2EE
> 1.4. Most servers are only certified for JRE 1.4 and that could be an
> issue for an API.
>
> Even if we specify the use of annotations for mailet dependencies, Java
> 1.5 would not be forced. Mailets could still be written for Java 1.4
> using another method for dependencies, like wiring by hand.
> (This would require compiling the API for 1.4 without the (2) annotations)

Well switching to jdk 1.5 whould give even more improvements for james.
We could for example switch to mina (after finish handlerapi) and use
SSLFilter for STARTTLS support etc. Generics whould also be cool for
avoid all the ClassCastExceptions we had in the past.

bye
Norman