james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 04:18:12 GMT

A small point (on the otherwise fair rollup below):  An individual 
changing their mind on a subject or even moving slightly can be a good 
thing.  Typically school leaves us westerers with a 
don't-admit-you're-wrong-or-say-you-are-sorry attitude, that affected me 
personally until I was about 25. I'd like to apologise to all those that 
suffered unjustly at my hands before then ;-)

>Danny Angus:
> -1: org.apache.avalon.framework.logger.Logger getLogger();
>Fine.  One of the purposes for putting forth this strawman was because I
>perceived a certain amount of flip-flopping on the issues.  For example,
>this was your original stance, but I perceived you to change your mind in
>some of your replies to Paul, after he explained that the logger framework
>was purely an interface.
> -1: org.apache.avalon.framework.logger.Logger
> -1: logging in the Mailet API at all
>     Alternative:
>I understand Danny's point.  I related that point several times to Paul, but
>I perceived Danny to flip-flop, which is one of the reasons behind this
>I strongly DISAGREE with removing logging from the Mailet API.  You look at
>the logging in James.  Go ahead and remove it all.  I dare you.  ;-)  Humor
>aside, there is clearly a need for components to have a standard,
>platform-neutral, way to log information.
>Your alternative does us no good, because it creates platform specific
>matchers and mailets.  We need to specify the interface for logging, so that
>components can log regardless of which platform they are running on.
>Andrei Ivanov:
>>This solution still stores all log data into one file.
>No it does not.  It says NOTHING about the implementation.  It only
>specifies the interface.
>>Can "per mailet" logger configuratuon be implemented?
>That depends upon the implementation of getLogger().
... and up to the container.  The container may even want to have a JMS 
impl of logging to fire off log events to some remote manager.

>>Why GenericMailet can not simply extend AbstractLogEnabled
>Because Danny does not want to "contaminate" the Mailet API with Avalon
>Frameworks.  I am not agreeing or disagreeing at the moment.  I am trying to
>get the options explored in concrete terms.
>Now, Paul and Nic want to go the Avalon Frameworks route.  Instead of
>defining an interface that tells a Mailet that it can have a logger, there
>is nothing in the Mailet interfaces that would suggesting logging is
>possible.  HOWEVER, the abstract base class implements LogEnabled, and that
>tells the mailet container that it can (and should) setup logging on that
>Mailet.  The definition of the abstract base class would be part of the
>Mailet specification,
The abstract base class is optional of course.  An individual MAILET 
could choose to implement LogEnabled directly (or not at all). 
 AbstractLogEnabled is
an almost insignifiant time-saver.

> so that's not a bad thing, just rather a different
>approach from the current scheme, which borrows design ideas from the
>Servlet specification.
>Regardless of whether or not Mailets are running on a system using Avalon
>frameworks or not, there is a need for platform-neutral logging capability.
I'm confused about the use of the word 'platform' ;-) Noel dude, could 
you elaborate :-)

- 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