Noel,
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.
>
>Serge:
>
> -1: org.apache.avalon.framework.logger.Logger
> -1: logging in the Mailet API at all
> Alternative:
>getServletContext().getAttribute("avalon.framework.logger")
>
>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
>exercise.
>
>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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
