> To tell the truth, the whole idea of using JNDI for standard resource
access
> doesn't sit all that well with me. The JNDI Context interface just seems
too
> broad and too general for what we want to achieve.
I appreciate this view. A lot of people have been scared away from JNDI
because they view it as a complicated thing. But it need not be, and isn't.
As noted, it has become an integral part of J2EE programming, included in
the Servlet Specification, as well as other places. If you look at its use
in those contexts, it is simple and straightfoward.
> 1) Is there a close match between the javax.naming.Context interface, and
what
> we want to provide to mailets? Do we want to provide a mutable context
to
> Mailets?
I don't see this as an issue. It has already been resolved for J2EE. There
are constraints over mutability.
> 2) Will using JNDI be easier for a Mailet author than, say, something like
an
> Avalon Context?
A consensus was to not adopt non-standard interfaces into the Mailet
Specification. JNDI, JAAS, JDBC, JavaMail, etc., are all standard
interfaces.
> 3) Will using JNDI make it harder to provide a controlled, constrained
environment for running Mailets. I'm a fan of IoC, and I think we need
to
keep control over what each Mailet can access.
I believe that it is unnecessary to do it per-matcher/mailet. We could do
it the same way that the Servlet Specification does it: per-"webapp", i.e.,
per-classloader. There are a variety of choices for how we might define
what gets a unique classloader. Packages, sets of packages, processors, ...
*if* we need to do it.
A lot less overhead than per-class classloaders, and provides administrative
control over JNDI context(s). It would also relieve Aaron of having to hack
around JNDI usage patterns. If something like this becomes desirable, we
can easily address it when we discover the need, and we'll adjust how we
define resources.
> 4) Are we better off adding explicit lookup (and bind) methods to the
Mailet
API? Will this be clearer for Mailet authors than a simple, "for
anything
else you use JNDI"?
Not in my view. We'd be just another ad hoc API that had to keep changing
each time we had a new justifiable feature request. Plus, we would lose the
benefits of people using a standard API. We may very well have some
convenience methods.
> 5) The hard part of resource provision is allowing Mailets to "declare"
what
> they need, and for containers to set up their environment accordingly.
The funny thing is that both you and Aaron talk about this, but the simple
fact is that James doesn't do that at all. The MailetContext is shared
across all matchers and mailets, with no separation or security. If you
look at config.xml, and then attempt to add to each matcher and mailet a
list of all resources that each needs, I think you'll rapidly become sick of
it.
> The Servlet API just avoids this, it seems, by assuming everything is
already
> there in JNDI under well-known names.
The well-defined names issue exists either way.
--- Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
