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: Finer Logging Control for Mailets/Matchers
Date Sun, 09 Jun 2002 02:38:56 GMT
Do we really need such logging capabilities?  You're adding a capability 
which has been addressed multiple ways with multiple approaches, so 
trying to pick one way will undoutedly favor one of those approaches. 
Moreover, this would raise the bar for what a mailet container needs to 
implement.

I'm thinking that logging beyond a log() method should be left out of 
the API and instead leave it to an implementation like James to provide 
their custom way of special logging.
-- 
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com/

Noel J. Bergman wrote:
> Paul,
> 
> I believe that Danny's point is this: "Because other applications which use
> mailets to process mail might not have or want avalon ..."
> 
> Therefore, he wants an org.apache.mailet.Logger interface, even if the
> implementation of MailetContext.getLogger() returns an Avalon object.  The
> Mailet Logger API might not differ from the Avalon Logger API, other than to
> effectively put it in the "right" package.  So the James implementation can
> happily use Avalon, since James is an Avalon applcation, but mailets should
> not have to import anything other than org.apache.mailets.*, java.* and
> javax.mail.* in order to access the Mailet API.
> 
> The Mailet API definition will be interesting later, because such things as
> a mailing list mailet want to be able to control the underly mail platform,
> not just manipulate message content.
> 
> 	--- Noel
> 
> -----Original Message-----
> From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
> Sent: Saturday, June 08, 2002 17:14
> To: James Developers List
> Subject: Re: Finer Logging Control for Mailets/Matchers
> 
> 
> Danny,
> 
> 
>>>I agree ... so please explain exactly how this "wrapper interface" would
>>>differ from the logger facade in org.apache.avalon.framework.logger.  Are
>>>you simply saying that you want to put a facade over their facade so that
>>>the naming space is part of the Mailet API instead of Avalon?
>>>
>>>
>>
>>Yes, in a nutshell.
>>Because other applications which use mailets to process mail might not have
>>or want avalon or log4j or whatever.
>>
> 
> Avalon is a project. I think you are referring to Logkit.  You will find
> that there is a truly excellent abstraction called LogEnabled in the
> Avalon-Framework interfaces. We have already implementations for this
> that route method invocations to Log4J, LogKit, JDK1.4 logging, The
> console and null: This is a really great API for an implementation
> neutral API to implicate.
> 
> The Avalon-Phoenix container patches such calls thru to LogKit. The
> maillet API being evolved naturally will not name Avalon-Phoenix as a
> pre-requisite.  JAMES (the reference impl of the maillet API) sits on
> Phoenix.
> 
> - Paul


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