> Its the per component subject I'm thinking about.
> This seems terribly complicated as compared to the approach of a
> component declaring what it needs
Only if it is important to provide a per-component set of resources. That
is the Avalon way, but it is not the J2EE way.
> > However, my proposal wasn't an attempt to implement IoC.
> I though we were discussing the mailet API
> What I am very interested in is the contract between a mailet
> and its container (which is more than the Mailet API itself).
Agreed. Hence my use of the term Mailet Specification. And that contract
is what is the topic of discussion.
There has been a lot of discussion, but never a resolution, on the subject
of how to provide access to more sophisticated resources. Although adopting
Avalon interfaces, such as Context, into the Mailet Specification has been
suggested, so far that suggestion has not been adopted. Stronger statement
is that it has been rejected, but I'm willing to float both ideas side by
side, as I did in my initial posting on this proposal.
One difference between the two amounts to how the context is acquired. If
we adopt JNDI, a mailet would typically create an InitialContext instance
and access things via it. If we adopted the Avalon approach, a mailet would
be passed a context via a declared interface.
There are other differences. A JNDI context is not a bean that has to be
cast to another type, nor is it only a lookup object. I can take the JNDI
context and add items using it, such as adding an attribute to a directory
entry. I can search using a JNDI context.
One of the appealing things about JNDI is that it provides a uniform
resource access model. The fundamental data model is a searchable,
hierarchical, linked graph of addressable nodes with attributes. The JNDI
access model includes the ability to mutate the contents.
These may not be things that Avalon wants to support via a Context, even for
A5. The focus of the Avalon Context has been the secure provision of only
those resources that a component is entitled to have via a configurator.
That is not the same design goal as JNDI. The only method on Context in A4
is a get, but even if Avalon decides to support those things in the future,
it does not support them today.
JNDI can be a bit of work to learn at first, but programmers who use J2EE
(e.g., Tomcat) will have familarity with JNDI, reducing their learning
curve. And we can leverage other tutorial content (and code).
I am not suggesting JNDI for everything, as I noted to Aaron and Harmeet who
suggested using it as the message store interface. JavaMail is appropriate
for that domain.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
