james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: JNDI Mailet Configuration
Date Sun, 02 Feb 2003 15:03:23 GMT
> > The issue, Aaron, is whether or not it is acceptable to require JNDI for
all
> > Mailet containers.  Sell that point, and we can discuss the rest of this
> > message.  Until then, it is a moot point.

> Er - isn't this a bit of a rule change?  We don't even have a container
> spec yet and already you want a micro edition?

A requirement for lightweight containers has been mentioned on the list,
primarily by Danny.  If requiring JNDI is acceptable to everyone, fine.  But
if not, then the specification can't require it for fundamental behavior.

> I thought you were proposing that JNDI be expected by the Mailet?

I am proposing JNDI as the mechanism by which all resources not provided by
the Mailet API are exposed to mailets, not as a core mechanism required by
all mailet containers.

> I agree that implementing a lightweight container would be made more
> difficult by requiring JNDI.  I have not, however, seen any discussion
> of this requirement in the past.

I understand.  You can probably find some of the discussion in the archives.
Danny is probably the biggest proponent.  I'm simply pointing out the issue.

> They would not be able to have user or mail repositories.
> How would you provide access to other processors without
> providing access to the spool?

Matchers and mailets are isolated from the spooling mechanism.  A property
on Mail is used to control message flow through the container.

Please note that prior to post-v2.1 changes in HEAD, the Mailet API
consisted only of Mailet, MatcherConfig, Mail, MailetConfig,
MailetException, Matcher, MailAddress, MailetContext, and some generic
classes.  Only a handful of Matchers or Mailets use anything more that those
interfaces.

In order to explore issue of extending the Mailet API, Danny moved
interfaces for user, mail and spool access.  I think that those will all be
replaced at the end of the day, perhaps by JNDI, JavaMail, and something
else.

> Let me get back to basics here.  My own business requirements
> are as follows:

> 1) Provide access to MailRepositories via a standard mechanism
>    that is not subject to change in the next James release.

One proposal is to use JavaMail.

> 2) Provide the ability to pass of certain messages to another
>    processor to be processed asynchronously.

Spooling mechanism.  I am leaning towards one of two solutions.  T-spaces is
one, but it may not be the best.  The other is possibly providing
specialized implementations of classes from util.concurrent / JSR 166 that
provide persistent queuing behavior.

> 3)  Provide support for structured configuration.
> 4)  Scale James to around 50 messages per second.

> I believe that per-mailet Contexts are a great way of achieving 1 and 3.

I'm not sure how it applies to #1.  As for #3, remember that my proposal was
for matchers and mailets that require more sophisticated configuration to be
provided that as a resource.  That means that you'd have precisely the
configuration that you're proposing, without eliminating the simpler
getInitParameter for the bulk of matchers / mailets.

> 1)  Pass "this" to the constructor of InitialMailetContext, or
> 2)  Call Mailet.getInitialContext()
> Neither of these are prone to error.

The problem with Mailet.getInitialContext() is that it couples JNDI with the
Mailet API.  I had a comment in my message that I removed regarding the
other method.  The comment was about using something like a convenience
method to wrap the standard constructor that takes an environment.
Underneath any convenience method, we should still be using standard JNDI
interfaces.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: james-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: james-dev-help@jakarta.apache.org


Mime
View raw message