I agree with Andrew.
1) Imho we can target java 5 for next mailet apis (so we can use
annotations)
2) Mailets dependencies/configurability *declaration* must be defined by
the api
3) Mailets configuration and deployment wiring are vendor specific and
anyone will decide how to provide this.
If we don't want to require java 5 then we have to define a mean for the
mailet to declare their dependencies: an xml file (maybe xdoclet
generated) or the implementation of specific declaring interfaces are
two alternative solutions. My personal idea is that we are discussing a
future api while sun is releasing java 6 and java 2 1.4 will be probably
EOLed soon.
Stefano
Andrew C. Oliver wrote:
(sorry if there are two I fat fingered)
I'm still waiting for someone to give a sensible DI example that would
show how we deal with the fact that there can be an unlimited number
of unknown dependancies.
[...]
CONTRACTS:
Constructors are called in any order. Each mailet has a method called
start.
Each mailet has a method called stop.
Attributes are "set" after construction but before "start".
Interfaces are proxies (ala java.lang.reflect.Proxy) and thus can be
passed before the service is started
Start is then called once dependencies are satisfied (below).
Mailets with no <depends>true</depends> are started first.
Mailets whose dependencies are satisfied are started next (loop).
Mutual and circular dependencies are not allowed (error).
JNDI dependencies are satisfied when the jndi lookup exists and the
service has been started.
stops are called in reverse order that starts were called.
Notes:
attribute annotations can be either on the implementation or the
interface. constructor annotations must be on the implementation (duh)
annotations and/or XML are equivalent
annotations should not be used for configuration (vendor specific
example in xml above)
This is more or less the same idea used for JBoss XMBeans, Geronimo
GBeans, and EJB3.