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. ;-)
