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: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 19:14:18 GMT
> I've written a lot of servlets that needed tweaking from one servlet
> container to another.

That means that there may be an opportunity for improvement in the
environment, not that it should be considered a normative condition.  Note
that I did NOT say in the Servlet API, but in the common servlet

> The goal of the API is not 100% platform independence in every case
> so much as a baseline that multiple containers can implement.  You
> can always write code that can't be ported.

Write Once, Run Everywhere is still the goal.  Yes, there are always going
to be domain specific areas, but the more we learn about commonality, the
more we can facilitate portable code.

> How do you reconsile the following... James provides POP3 access.  Other
> mail servers will not have any local repository, simply functioning as a
> mail processor/gateway.  If the mailet API specifies how to interact
> with user inboxes, then what is the other mail server going to do since
> it does not support the concept?  On the other hand, if the mailet API
> does not support user inboxes, then you're going to have a mailet (or a
> few) that will need capabilities outside what the mailet provides that
> is tailored to James.

Let me get back to the limited server in a moment.  As for Mailets that DO
need the services, I raised that point to Danny a couple of weeks ago:

> But at the moment there is a good deal of environment exposed to
> Matchers and Mailets.  ComponentManager, DataSourceSelector;
> various stores, repositories, contexts and configs; etc., not
> counting Mail and MimeMessage. I'm sure you realize better than
> most what it will take to remove all import org.apache.avalon.*
> from matchers and mailets, not to mention org.apache.james, so
> that all that's left is org.apache.mailet.* and javax.mail.*.
>  Until and as that API is defined, I don't see any feasible
> decoupling of the Mailet API from Avalon.

Danny agreed, and replied:

> I take your point, and agree that any decoupling may have to define a
> repository interface and the context may have to provide some new services
> for the mailets, but the API doesn't have to provide those services, just
> define what is minimally required. it would then be up to implementations
> provide them

I agree with that point.  The question is where and how to do that
decoupling.  One option is to add those interfaces into the API (not the
implementation), the other is to use the Avalon model of composed
interfaces.  Either way, you need to account for them.  One way Danny
mentioned was:

> As far as mailet API dependancies on james utility classes, that just
> requires a simple re-factoring to deprecate the classes in o.a.james in
> favour of identical classes in o.a.mailet.

As far as repositories, etc., his comment was "I know that there is work
involved in this, and I do still believe that it is worth embarking on it."
The truth is that I agree with him, and support the goal of multiple Mailet
container implementations.  We're all just talking about how best to
accomplish the goal of a Mailet and Mailet Container specification.

> we made the decision a while ago that we wouldn't add user
> or message repository to the mailet API.

Danny, at least at the time, acknowledged that the Mailet specification
would need to address this.  And I agree that "there is work involved in "
coming up with a suitable INTERFACE, but "it is worth embarking on it."

Now, back to your other question "what is the other mail server going to do
since it does not support the concept [of inboxes or repositories]?"

The answer is that it depends.  It depends upon how we specify things.  This
is part of the challenge.  Right now, the Mailet requires a store component
from the context:

  compMgr =
  MailStore mailstore =

This happens to occur at init() time.  The mailet can notify the container
that it is not able to perform its function, and the container can report a
configuration error to the administrator.  This is not a local vs remote
issue -- a repository could be available via RMI -- this is a deliberate
case of this container not wanting to mailets to have access to

As I understand it, the Avalon "Best Practice" on this would be to have
Mailet components be composable.  If the configuration for the component
said that it needs the MailStore service, the container will (a) know, and
(b) make it available early in the component's lifecycle.

I believe I am correct about this (and this also seems to be Nico's
suggestion).  If so, I hope that Paul's example Mailet Container, which he
has indicated he will post, will illustrate this point.

As to the nature of Repositories and Stores, we already have interfaces for
UsersRepository, MailRepository, SpoolRepository, MailStore, etc.  If those
are sufficient, then we just use them with composable mailets.  If not, then
perhaps the most flexible approach would be JNDI with some specific helpers
to make life easier.  Some aspects of JNDI make sense (keyed access to node,
dynamic keyed attributes on node), if we can keep it SIMPLE for simple

> We have a servletContext.log() method.

A number of voices have said that they want more.

> If mailet authors need more, they can figure out the best way to do for
> situation.

That is what causes the anarchy.

> There may be a failing in the James/Avalon-framework documentation
> or offering at this point if it can't expose a way to log, but I
> don't see why it's the mailet API's fault that there is software
> anarchy.

The problem isn't that Avalon-Framework has a failing.  The issue is whether
we are willing to mandate that Mailet containers must support the Avalon
programming model, as proposed for JSR 111.  As I understand it, this
requirement does not impose significant development requirements on the
container, but does result in benefits.  We'll see at the weekend, when Paul
provides his proof-of-concept container.

> Frankly, I don't feel smart enough to know what the best solution is,
> so I don't want to add logging to the mailet API and impose my
> technical opinions on other mailet developers.  I don't think it's
> appropriate to say SHALL.

If we go with the Avalon model, then if someone didn't like interface A, and
came up with a better A', they can instrument the container to support both
components that use A, and components that use A'.  This future-proofing is
one of the benefits.

> How about we separate reference implementation mailets from James mailets?

Reference mailets, as it stands, are limited to javax.mail.* and .log().  No
one could implement mailing lists or all sorts of other mailets that need
not be James-specific.  I think we can do better.

> Or freedom. :)  Seriously, if someone had come up with an API that
> solved every need, then there wouldn't be so many offerings.

Not so.  The parallel development because of a lack in the common API.  Now
there is a JSR to reestablish sanity.

> I bet I would win a dripping-sarcasm competition if we wanted to go down
> that road.  I don't think that was Darrell's point.

Not trying to be sarcastic, and if I missed Darrell's point, I apologize.
In fact, the interface I mentioned need not actually be that far off from
reality if mailet components followed the Avalon model.  What is the
fundamental thing that a Mailet does?  It services the mail request.
Configuration, context, logging, storage, etc. are all generic items that
could be applied to the mailet component as needed, but would not be part of
the Mailet API per se.

	--- Noel

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

View raw message