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 Wed, 12 Jun 2002 21:19:59 GMT
> Ok, then I'm not sure why you're discussing changing the mailet API.
> What need is not being met?  Is it just complete portability?  What
> functionality do you think should get incorporated into the mailet API
then?

Ok, let's back up ...

This started from two concurrent activities.  On the one hand, Danny had
started to make some comments wherein he expressed a desire for Mailets to
be portable to multiple implementations of a Mailet Container.  He has
stated a desire, proposed if you will, that mailets depend on nothing more
than org.apache.mailet.*, javax.mail.* and java.*.  I believe those to be
demonstrably insufficient, with supporting proof being the current set of
mailets, which cannot be implemented using just those interfaces.

At the same time, we had several requests for improved logging.  Very early
on in this discussion, I made a suggestion about exposing getMailetLogger()
as a quick solution within the context of the current API.  Andrei was in
favor: "the sooner the better", but you replied: "I'm not happy with that
change just yet.  This requires a change to the mailet API, which is
something I want to discuss much more before changing."

So, we're discussing the Mailet API, although I think that term turns out to
be a bit of a red herring, since no on really wants to clone things into the
Mailet API.  We are really discussing what packages are supposed to be made
available to mailets regardless of whose mailet container is being used, and
then how those packages are to be provided to the mailet at runtime.

Logging is just one aspect of it.  Initially, I thought that it might be a
simple area to address, but it turns out that the discussion of logging is
really a discussion about the very nature of what goes into the Mailet API,
and how it interacts with other packages.

I'll dispense with the review of history and misunderstandings, and suggest
that on most points we're almost in violent agreement, rather than
disagreement.

> If a developer wants serious logging capabilities, he/she can either
> use [the logger if his/her choice.]

That might work for mailet authors, but I believe that it leads to chaos for
the poor administrator who would have no cohesive log for his/her mail
server.  Regardless of whether a mailet gets a logging service from the
MailetContext or through the mechanism advocated by the Avalon Frameworks
designers, we can provide a common interface to logging, just as we can for
the other domains you raise below.

> Sorry, I don't mean to sound like a broken record, but I just wanted to
> clarify the context of the discourse as I remembered it.

I understand that we're all trying to understand each other's points.  No
one is being acrimonious.  Although the discussion hasn't been as linear as
one might like, I don't see things going in circles; rather we're spiraling
towards some agreement (the final shape of which is still TBD).

> Again, I'd like to hear what you want to add to the mailet API.

Again, not necessarily anything.  The Mailet API may not be the thing
changed (other than perhaps to deprecate things that will be covered
elsewhere).  All that I want is to ensure that a set of common and necessary
services a mailet wants to use are going to be available consistently and
configurably on any given mailet container.

> I guess I would only suggest you take a look at the "competing"
> solutions to mailets right now.

Are there any?  ;-)  Not in my book.  :-)  I am not forced to be here.  I am
here for the simple reason that James has the potential to do what I want
better than anything else of which I'm aware.

> Few of them have any concept of user repositories, message repositories,
> application logging, or other enterprise mail server features.  None of
> them really grasp the power of Java, and that's hopefully part of why
> mailets are the right answer.

Mind you, repositories are only available because the Avalon Frameworks are
exposed.  MailetContext.getAttribute(String) is the all encompassing
catch-all for getting at services, and the docs say that it is container
specific.  If we want portable mailets that can do more than just filter the
content of the MimeMessage and redirect processing, we need to do something
... which gets us to the next point.

> But I'm not sure if we need to create new API (and especially need to
> touch the mailet API) to support these concepts.  Maybe we can map out
> what we need in terms of "Enterprise Mail Server Services" and find
> existing Java APIs that fill these needs.

I agree with this.  This is what I mean when I say that we don't necessarily
need to expand the Mailet API (the mailet package), but rather we can
address the issues by specifying the other packages that a Mailet container
shall make available.  One way to do this is by adopting Avalon frameworks
and the programming model used there.  I asked Paul about a sample container
so that we could see what that would entail; he's agreed to do one.

Alternatively, we could keep going the way that the API is currently
structured, but specify a core set of services that containers need to make
available through the MailetContext.

The difference between those two is partially how/when the binding between
components occurs.  As for the specific interfaces we might adopt ...

> For user repository API... well, JNDI would work, right?

We'd have to write both some backend code, and some utilities to make life
palatable for authors.  JNDI is not fun, and is generally massive overkill
in the typical case.

> Then message repository API we build as implementations of JavaMail's
> javax.mail.Folder (actually doesn't look as irrational as you might
> think).

I don't know enough about that package at the moment to comment.  Since that
is your suggestion, why don't you elaborate on your idea(s).

> Logging I think is pretty easy... JDK 1.4 is readily available,
> or heck we're on Avalon-framework so just use that API.

> I've really really wanted to expose the db pooling as a
javax.sql.DataSource

> I think the more we rely on other existing Java API, the easier it will
> be for mailet developers to get up to speed, and ultimately the more
> portable mailets will be.

These exemplify what I've been saying.  The point is not changing the Mailet
API, per se, but being willing to specify additional packages that we adopt
to model necessary "Enterprise Mail Server Services", and make them part of
the Mailet specification that containers must support.

The simple fact is that we cannot have a portable mailet container without
(a) addition to the Mailet API (-1), (b) specifying other packages that
shall be available to Mailets (+1), or (c) significantly restricting what
mailets can do (e.g., eliminating access to users and stores) (-1).

	--- Noel


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


Mime
View raw message