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 15:29:56 GMT

No ... I understand the difference, although I thank you for the
clarification.  Yes, those are just interfaces.  But they are "Avalon
interfaces" by simple virtue of the package name.  The package is named:


That is part of the "Avalon" set of packages, even if it is completely
independent of other parts, such as Phoenix.  It isn't, for example,

I am not saying that Danny is right, wrong, or indifferent.  I am saying
that he indicated that he did not want the Mailet API to have any references
to packages other than org.apache.mailet.*, java.* and javax.mail.*.

> You are going to end up with an undeniable knock-off of LogEnabled

No kidding.  As I said, "The Mailet Logger API might not differ from the
Avalon Logger API, other than to effectively put it in the 'right' package."
Note the quotes in my original statement.

I agree that you've made a case for the Mailet API to use the abstract
interfaces defined by the Avalon Framework, on the grounds that they are
purely interfaces, implementation independent, easily be mapped onto other

	--- Noel

-----Original Message-----
From: Paul Hammant [mailto:Paul_Hammant@yahoo.com]
Sent: Sunday, June 09, 2002 3:39
To: James Developers List
Subject: Re: Finer Logging Control for Mailets/Matchers

Noel ,

_Please_  Avalon-Framework not Avalon.

You're wrong too....you mention 'Avalon object' (again context is
misleading) yet the LogEnabled.java is an interface.  For alternate
containers, it would return an alternate-conatiner object. For JAMES it
would likely return a JAMES object, that might delgate thru to the A-F
LogEnabled obj passed to it by the Avalon-Phoenix container.....

You are going to end up with an undeniable knock-off of LogEnabled.......

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

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