Danny Angus wrote:
> I *know* we've discussed this before, 'till we were almost ready to
> hit one another ;-) but here goes with a proposal.
LOL
You know ... one of the nice things about social bonding at ApacheCon is
that I really don't want to hit you anymore. :-p Actually, I don't recall
where we each came down on the various sides of this, so I am just teasing.
> Repositories MUST be available in all implementations of the API.
-1
I'll explain. I do not agree, and can certainly provide use-cases, for
implementations of Mailet API components that do not require access to a
repository.
> There is no concept of an implementation which only allows for
> pass-through processing because storage is always required for
> spooling.
Spooling should be transparent and separate, and does NOT always require
storage local to the Mailet Container.
HOWEVER, perhaps we can compromise on these various issues, including the DI
vs Service Locator issue, with a DI method for a repository locator:
<mailet match="..." class="...">
<matcher-property property="foo" reference="<specifier>"/>
<matcher-property property="bar" value="42"/>
<mailet-property property="oops" value="13"/>
</mailet>
A property could be any Java object, including a service or locator service
as desired.
I am not concerned about the specific syntax, just suggesting the concept of
declaring properties that will be inspected and injected by the container,
either by value or by reference (e.g., name, URL, etc.).
That handles arbitrary properties, but does require configuration. I do not
favor a purely deployment descriptor (XML config file) approach (nor do the
J2EE specs), which is neither convenient nor reliable, e.g., the config
doesn't reflect that the component requires a particular and standard
service. Therefore, for a stock set of bean properties, we could define the
required inteface/propertyName. Either way, during initialization, the
Mailet Container will inspect the interfaces of each component, and if it
cannot satisfy the implicit or explicit binding, will throw an Exception.
I'd like to hear people's thoughts on how we should address nested
configuration, such as where Mark Imel pierced the Avalon veil to support
the more advanced configuration required for the command-based mailing list
manager, since I'd like to see more advanced configuration options as
standard.
So I believe that the above could satisfy the needs behind your comments
that:
> A framework for deploying and accessing optional services is required.
> We need to have a service discovery function defined by the API so
> that new services can be registered and found without having to
> release new versions of the API.
but with respect to:
> I propose that these services (eg datasources, spam scanners, dns etc)
> be looked up in JNDI and that the API include a naming convention for
> their registration.
As much as I personally like JNDI, and agree that a service locator is
useful, the pattern adopted for the latest revision of several J2EE
Specifications differs. They make extensive use of annotation driven DI to
replace JNDI. Stefano also notes this, but may not realize that although
Sun documents this pattern in the specifications, they do not provide a DI
implementation outside of their proprietary com.sun.* packages. As I
understand what Roberto Chinnici told me this week, there is no standard DI
support for arbitrary containers, not even in Java 6.
The approach I propose above is a compromise for the lack of annotations and
DI support. I have written similar code that can map bean properties from
JDBC ResultSet objects.
Thoughts?
--- Noel
