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 Tue, 11 Jun 2002 23:34:48 GMT
Noel J. Bergman wrote:
> 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.

Ok, I take your point, but I haven't seen much discussion of this 
commonality.  The discussion is primariy comp sci pattern focused 
instead of usage focused.

 > [stuff deleted]
> 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 =
> getMailetContext().getAttribute(Constants.AVALON_COMPONENT_MANAGER);
>   MailStore mailstore =
> compMgr.lookup("org.apache.james.services.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
> repositories.

I think I'm missing the criticism of this approach.  The mailet API is 
allowing you access to container specific features.

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

What you call future-proofing, I would call adding a bunch of imports 
and implements for no benefit to someone as a non-interface A user. 
Yes, you can always add implements statements without changing 
functionality.  But, I don't think you would want me to send you some 
com.lokitech.mydesignpattern.* files to have your classes implement.

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

What logging capabilities does a mailing list need that log() doesn't 
support?  How many listsoft or ezmlm admins look at their log files?

The storage issue is much more difficult.  I honestly can't see how you 
standardize an API around tailored multiple applications.  Start with 
the user repositories... I can think of half a dozen very different ways 
that a mailing list might work.  It could just be a list of subscribers 
(email addresses), they might want to flag who are moderators, who are 
owners, who can only post, store per message for each user what bounced 
recently, store warning levels, store language preferences, digest 
preferences.  I think user API issues are an order of magnitude more 
challenging than logging API, which I [still] contend all people can't 
agree on.

And to some extent, we've tried to create a standard user repository 
API... it doesn't quite work though.  The idea was to let a standard 
user repository API support POP3 logins, SMTP auth, mailing lists, and 
anything else.  But virtual domains are a big wrinkle for POP3 logins, 
mailing lists need a ton of possible attributes and potentially need 
mapping to a message repository on a per user basis.  It's forced a 
dumbing down of features for the most part (we still don't have a real 
mailing list app and we still don't have virtual domain support.)

Anyway, my point is you probably need an ezmlm API and other application 
specific APIs, and I haven't heard what common, well-understood 
functionality is out there that is ripe for sticking in the mailet API.

>>Or freedom. :)  Seriously, if someone had come up with a [logging] 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.

Ahem... JSR 47 HAS produced a common API for logging.  It's called 


Beware of the rotten tomatoes incoming from the Avalon developers.  :) I 
have great respect for JSRs, but apparently they couldn't build a spec 
that solved all logging needs.

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

I guess I still don't see what you're suggesting that James + 
Avalon-framework doesn't already do.  You've got a mailet API... you've 
got composable, etc-able interfaces that you can get as servlet context 
attributes.  You can log, you can store, and whatever else that the 
Avalon-framework is providing.

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