james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: [Mailet API] Logging Proposal
Date Thu, 13 Jun 2002 02:21:58 GMT
Noel J. Bergman wrote:
>>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 expect we'd add getInitParameter(String) to MatcherConfig so that it 
matched the method signatures of MailetConfig (and ServletConfig).  (I 
don't think any James committer is considering the use of the Avalon 
framework in the mailet API.)

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

Ok, I don't think I can be much more concrete as to why I don't agree. 
Put it this way... go try to convince the Avalon community to integrate 
log4j or even just drop the idea of their own logging API and use 
java.util.logging.  I think your personal direct pleas will have an 
order of magnitude more impact than whatever we put into the mailet API 
(although I'd expected 0 to be convinced either way).

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

Really??  Wow, that's a first.  Maybe you can support help support the 
james-user list. :)  The configuration seems to confuse and frustrate a 
lot of people....   Yes, it's powerful... I just haven't heard people 
call it easy.  Cryptic error messages, no line numbers, conf files that 
can't be edited until you've run the app once (and in the future, the 
first time must be modified *while* the server is running or 
avalon-phoenix will delete the unmodified conf file).

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

Ok, then let's work up a user repository.  The one we have is too 
restrictive.  You can't run even a basic listserv with it (let alone 
something like ezmlm), and it can't support virtual domains... 
Independent of how we contextualize, compose, initialize, and otherwise 
block/service (i.e., the avalon-framework interfaces issue), what would 
the user repository API look like?

And yes, this shouldn't be in the mailet API, IMHO.  The repositories 
we've defined to date don't serve our current basic requirements, and 
they are already getting too complicated for your average sendmail admin. :)

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

I'm assuming in the 3rd example that LogEnabled is an Avalon-framework 
class, so correct me if I'm wrong, but you've stated 3 ways we could 
integrate Avalon-framework into the mailet API.  Feature issue aside, I 
don't see this happening with the mailet API.  Again, I think you could 
document with James how to get to the logger object... but that wouldn't 
be related to the mailet API.

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

Just to be clear, are you suggesting we add interfaces that don't go 
into the mailet API, but are in the mailet specification document?  How 
do you define an interface contract for mailets and not call that part 
of the API?

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

Ok, I guess we just disagree.

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

Yes, I agree completely.  I tried to list a bunch of mail servers where 
mailets could run, that don't have the features you want.  Again, I 
guess we just disagree on what the minimum mail server is.  I feel the 
bar you're setting is only providable by James, which doesn't make it 
much of a standard API.

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

Maybe from a different angle I would say there are about 100 times as 
many developers building servlet containers than mailet containers, and 
there are probably 100,000 times as many servlet applications than 
mailet applications.  The servlet API has the same level of primitive 
logging that the mailet API has.  If you're so sure mailets need this 
logging uniformity, why have servlets thrived without it?

Serge Knystautas
Loki Technologies - Unstoppable Websites

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