james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Danny Angus" <da...@apache.org>
Subject RE: Finer Logging Control for Mailets/Matchers
Date Mon, 10 Jun 2002 13:34:10 GMT

> I thought I read about a simple log(String) method...
> I agree that the Mailet API should not legislate on logging, and
> delegate (in our case) to the Avalon Apis, that are made just to do this
> "legislation".

Put it this way;
The void log(String message) method exists in Mailet 1.2 and in Servlet 2+,
it is heavily used in James mailets,
I don't feel so stongly about it being inapropriate that I would deprecate
it, but if I was starting from scratch I would probably omit it.

> Ok, so let me push this discussion a bit further.
> The Mailet API is basically the Mailet interface(s) and the Context.
> Most of the problems with defining a server api come from the definition
> of the container in fact, with regards to common services: logging,
> getting other services, Context, etc.

Yes, I agree, I also believe that it should be a goal to make the Mailet API
completely self referential, and that a goal isn't necessarily pointless
just because it isn't ever achieved.

However there remains the issue of exacly those two situations you mention:

> MailetConfig: Configuration-Configurable
> MailContext: Context-Contextualizable

It seems reasonable to consider avalon.framework for this but I'm going to
examine the whole of avalon.framework (a.f.) quite closely before I commit
myself, amongst other things I need is some indications of the maturity of
a.f (rate and impact of change) an understanding of its evolution, and how
that would effect Mailet in the future.
In particular if Mailet 2 is a success and generates a lot of Mailet2
applications I don't want new mailet 2 container implementations to have to
use a stored snapshot of a.f. made sometime this month, nor do I want
maintenance of Mailet 2 to be dominated by changes driven in by a.f.

I'm not singling out a.f for harsh treatment I would apply the same criteria
to any proposed dependancy including javax.mail, but in fact we are well
aware of the strengths and weaknesses of JavaMail, the opportunity cost of
not using it, and its fitness for the purpose to which we intend to put it.

Beyond that I think it is not unreasonable to have dependancies within
Mailet that are invisible to Mailet writers, and don't represent significant
burden on container implementors.

d.



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