james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: Finer Logging Control for Mailets/Matchers
Date Mon, 10 Jun 2002 13:44:08 GMT

Danny Angus wrote:
>>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.

Makes sense.

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

Yes, I understand.

> 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 agree, and see your points, having burnt myself over Avalon changes.
Now I'm a committer at Avalon, and they will have to go over my dead 
body before making a revolution ;-)

Anyway, we are discussing the new Avalon 5, and we have agreed to use 
evolution, not revolution.

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

No prob, it's not "harsh treatment", it's reasonable doubt.
Look at the framework and we will discuss on the "meat" :-)

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

Exactly:
1. invisible (ie trasparent) to users
2. no significant burden on container implementors

I think that Avalon-framework has these points.
Take a look at it, and it would be cool if your suggestions on how they 
could be better would go in the Avalon5 discussion.

:-D

-- 
Nicola Ken Barozzi                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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