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 Thu, 13 Jun 2002 00:22:23 GMT

> I'm sorry it seemed like a red herring.
> I'm sorry if this seemed like I was just throwing out a red herring.

???? I'm shocked.  How did you think that I meant you?  I meant that the
issue of logging in the Mailet API turns out to be a bit of a red herring (a
false direction for us to take), in that what we (collectively) think that
the issue is really somewhere else (which we're agreeing upon).  I never
said that you threw out a red herring, nor would I present it that way.

[I'm rather curious as to why you'd think I'd accuse you of doing that, but
we can discuss that privately, rather than on the list.]

> The two changes to the mailet API that I thought might still go through
> are get/setAttribute on a Mail object, and adding name/value parameters
> to matcher configuration.

+1 on the former (not that I get a vote), but the latter seems dependent
upon whether or not how we adopt the use of Avalon Frameworks.  All of that
is already present in their configuration scheme, as we know from the other
parts of James using it.  One way or the other, I agree (+1) with the basic
notion of adding that capability.

> I guess I don't see how specifying a logging API will control developers
> and reduce the administrator's chaos.

If I have a dozen or more mailets, some of which log via Java logging, some
of which use Avalon Frameworks' logging, some of which use other logging
mechanisms, the mailet logs will be scattered and disjoint.  I see that as a
problem for admins.  If possible, I'd like to avoid that problem.  I do
think that it is possible to at least avoid encouraging developers to use
alternative logging mechanisms.

> Just FYI, off the top of my head here are other products that do what
> mailets do:

I could compare all of them in order, but leave it to say here that I have
looked at procmail, sendmail, qmail and JAMS.  None of them are as nice as
James in several regards, especially the way matchers and mailets combine.
James is not as fast or stable, yet, but it is architecturally lovely, and
has great potential.  Plus, James is easy to configure.

> I list these mainly because these could implement the mailet API if they
> wanted [(as possible mailet containers)]

If Mailets are to be first class parts of such systems, they should have
access to such things as user repositories.  Are you thinking that it is OK
if mailets have limited capability in such containers because any integrated
processing will be done with other extensions?

> could you expand on how a mailet container would make available
> packages that adopt the Avalon framework, without incorporating
> the avalon framework into the mailet API?

I don't think I said that, but in any case what I meant was that we could
have either:

 - org.apache.avalon.frameworks.logger.Logger getLogger();
 - logger = (o.a.a.f.l.Logger) =
getMailetContext().getAttribute("mailet.logger");
 - class MyMailet implements Mailet, LogEnabled ...

I'm not suggesting which to choose; just pointing out some (technical)
alternatives.

Please note: I am not talking about needing to access every package through
Avalon Frameworks or some alternative; I am talking about components that
are part of the interface contract between a mailet and a mailet container.

> In my mind that leaves us with mailing lists implementing
> a mailing list interface as they need it

I think we can do better even if we simply allow named properties on User
objects, e.g, User.setProperty() and User.getProperty().  Easy to map to
either storage mechanism, and provides most of the value that we need for a
tiny, tiny, fraction of the cost. [I deliberately said property; I don't
think we'd need serialized objects.]

HOWEVER, this should be part of the Mailet API (or part of a related package
that all containers are required to provide), so that mailets (can) have a
common interface to user repositories.  A container has to map this
interface to its user repositories.

> mailet < Enterprise Mail Server

Yes, but mailets are the primary pluggable component that we use to
implement customized mail handling in the server.  It is the "servlet" of
the mail server.

> I guess I just don't get (b) because this seems to say that we "give
> permission" to use javax.sql.DataSource in mailets.

That one was your example, so I kept it in.  I am only concerned about the
interface contract between a mailet and the mailet container -- both ways.
I do consider user repositories, spools, mailboxes, and other mail domain
concepts to be an extended part of that contact, even though one can
properly say that they are related to, not part of, the container.

Logging is an issue primarily because there is a reason for consistent log
handling, else I no more need for the container to give me a log than I care
for it to give me a file.  The container does not need to be the universal
factory of everything, just those things that make up the contract between
the container and the contained.

	--- 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