james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Finer Logging Control for Mailets/Matchers
Date Sun, 09 Jun 2002 02:59:03 GMT
Serge,

I agree with your other comments elsewhere (addressed in other replies), but
I don't agree on this one.  If a platform has a log(m) method somewhere, it
is trivial to mux .debug(), .info(), .warning, etc., into log(level + ": " +
m).  On the other hand, if the Mailet API has only log(m), we can't
assuredly demux the messages where desired.

So although most of my own code uses a simpler logging pattern, I'd just as
soon go with the current proposal.

	--- Noel

-----Original Message-----
From: Serge Knystautas [mailto:sergek@lokitech.com]
Sent: Saturday, June 08, 2002 22:39
To: James Developers List
Subject: Re: Finer Logging Control for Mailets/Matchers


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>


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