You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by "Noel J. Bergman" <no...@devtech.com> on 2002/06/10 21:11:06 UTC
[Mailet API] Logging Proposal
[Needless to say, these definitions include only the logging related
portion]
interface MailetContext
{
org.apache.avalon.framework.logger.Logger getLogger();
void log(String message); // deprecated
void log(String message, Throwable t); // deprecated
}
abstract class GenericMailet implements Mailet, MailetConfig
{
void log(String message); // deprecated
void log(String message, Throwable t); // deprecated
/*
allows getLogger()."cat"(msg[, t]) instead of
getMailetContext().getLogger()."cat"(message[, t]);
implementation may wrap the logger to include
config.getMailetName() + ": " in the message
*/
org.apache.avalon.framework.logger.Logger getLogger();
}
Alternative would be to break with the Mailet v1 API entirely, and go with:
interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
but I'm less inclined in that direction.
Please comment with specific changes (or even rewrites), so we can keep the
discussion concrete.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Andrei Ivanov <my...@surfeu.fi>.
Hi,
1. This solution still stores all log data into one file. Can "per mailet"
logger configuratuon be implemented?
2. Why GenericMailet can not simply extend AbstractLogEnabled and there will
be setLogger(...) for every mailet, say in MailetLoader? (what is actually
proposed in the end of your letter).
Andrei
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "James-Dev Mailing List" <ja...@jakarta.apache.org>
Sent: Monday, June 10, 2002 10:11 PM
Subject: [Mailet API] Logging Proposal
> [Needless to say, these definitions include only the logging related
> portion]
>
> interface MailetContext
> {
> org.apache.avalon.framework.logger.Logger getLogger();
>
> void log(String message); // deprecated
> void log(String message, Throwable t); // deprecated
> }
>
> abstract class GenericMailet implements Mailet, MailetConfig
> {
> void log(String message); // deprecated
> void log(String message, Throwable t); // deprecated
>
> /*
> allows getLogger()."cat"(msg[, t]) instead of
> getMailetContext().getLogger()."cat"(message[, t]);
>
> implementation may wrap the logger to include
> config.getMailetName() + ": " in the message
>
> */
> org.apache.avalon.framework.logger.Logger getLogger();
> }
>
> Alternative would be to break with the Mailet v1 API entirely, and go
with:
>
> interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>
> but I'm less inclined in that direction.
>
> Please comment with specific changes (or even rewrites), so we can keep
the
> discussion concrete.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
Serge,
>> Alternative would be to break with the Mailet v1 API entirely, and go
>> with:
>>
>> interface Mailet extends
>> org.apache.avalon.framework.logger.LogEnabled
>>
>
> -1 for Avalon dependency (danny's spoken on this), and -1 for logging
> in the mailet API. I don't believe there is clear enough demand for
> this, and the demand I do have seen has varied requirements.
You are misisng the fact that _all_ Avalon-Framework interfaces are
optional. The barest minimum MAILET API impl is :
MyMailet implements Mailet {
Blah processMailRequest(Blah blah) BlahException {
return null;
}
}
You are missing completely the nature and long development & design by
Apache luminaries of the framework interfaces. The container's role is
to see which of these interfaces the MAILET implements and decorate the
(with method invocations) accordingly.
There is no dependancy. They are container recognised optionals. This
is fundamental SoC, with the container decorating with method calls
according to IoC.
> I'd +1 an approach that leaves logging out of the mailet API but
> provides a convenient way to get a logger object from the container
> (maybe something like
> getServletContext().getAttribute("avalon.framework.logger")).
-1 ( I appreciate that according to my original contract with you folks
that my vote on JAMES matters is worthless).
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Serge Knystautas <se...@lokitech.com>.
Noel J. Bergman wrote:
> [Needless to say, these definitions include only the logging related
> portion]
>
> interface MailetContext
> {
> org.apache.avalon.framework.logger.Logger getLogger();
>
> void log(String message); // deprecated
> void log(String message, Throwable t); // deprecated
> }
>
> abstract class GenericMailet implements Mailet, MailetConfig
> {
> void log(String message); // deprecated
> void log(String message, Throwable t); // deprecated
>
> /*
> allows getLogger()."cat"(msg[, t]) instead of
> getMailetContext().getLogger()."cat"(message[, t]);
>
> implementation may wrap the logger to include
> config.getMailetName() + ": " in the message
>
> */
> org.apache.avalon.framework.logger.Logger getLogger();
> }
>
> Alternative would be to break with the Mailet v1 API entirely, and go with:
>
> interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>
> but I'm less inclined in that direction.
>
> Please comment with specific changes (or even rewrites), so we can keep the
> discussion concrete.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
-1 for Avalon dependency (danny's spoken on this), and -1 for logging in
the mailet API. I don't believe there is clear enough demand for this,
and the demand I do have seen has varied requirements.
I'd +1 an approach that leaves logging out of the mailet API but
provides a convenient way to get a logger object from the container
(maybe something like
getServletContext().getAttribute("avalon.framework.logger")).
--
Serge Knystautas
Loki Technologies - Unstoppable Websites
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>I cannot imagine *any* container written in Java that does not have the
>>capability to do instanceof.
>>
>>
>
>You miss understand. I do not mean that a container is somehow unable to
>have the capability. I simply mean that containers cannot naively assume
>that the Mailet interface is the only interface implemented by the object.
>
Yup. I can only imagine a max of say five containers for MAILET for the
first five years. It will be easy to ensure compatability. Especially
if the JAMES project publishes some 'unit test' MAILETs.
>They must go through the introspection process not only for possible
>"platform-specific" functionality, but also for optional
>platform-independent functionality, such as logging. This is nice way to
>add fine grained composition to Java, but it is not a common paradigm SO
>FAR.
>
We'll see. May other significant teams/projects have done the same but
with a knock-off of Avalon Framework interfaces, without
acknowledgement. With a smal refactoring that for the large part is
hidden from their user base, they could be Phoenix compatible quite
quickly...
>>>From some but not all quarters.
>>
>>
>
>Not from all, but some of them are key.
>
Agree.
>In any case, the purpose for the
>discussion is to look over and discussion the options.
>
:-)
>>>If these patterns were embedded in javax.frameworks.*, I doubt
>>>that we'd be having this part of the discussion.
>>>
>>>
>>JSR 111? [Aalon's Framework] is shortlisted as a candidate.
>>
>>
>
>Seems like the best choice I've seen so far. It is interesting to
>contemplate how other Java interfaces might be different if javax.service
>had been in place first.
>
>Actually, I would argue that even if Avalon Framework is not accepted, it is
>a safe bet to use Avalon's programming approach. Because whatever is
>adopted, post-JSR 111 Phoenix should be able to support both A-F and JSR 111
>objects.
>
Phoenix just being one container.
- Paul
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > class AbstractMailet
> > implements Mailet,
> > org.apache.avalon.framework.logger.LogEnabled
> > The container has to inspect the Mailet, since it does not know if
> > a Mailet implements LogEnabled. IF you have a container with that
> > capability, it is an appealing construct.
> I cannot imagine *any* container written in Java that does not have the
> capability to do instanceof.
You miss understand. I do not mean that a container is somehow unable to
have the capability. I simply mean that containers cannot naively assume
that the Mailet interface is the only interface implemented by the object.
They must go through the introspection process not only for possible
"platform-specific" functionality, but also for optional
platform-independent functionality, such as logging. This is nice way to
add fine grained composition to Java, but it is not a common paradigm SO
FAR.
> From some but not all quarters.
Not from all, but some of them are key. In any case, the purpose for the
discussion is to look over and discussion the options.
> > If these patterns were embedded in javax.frameworks.*, I doubt
> > that we'd be having this part of the discussion.
> JSR 111? [Aalon's Framework] is shortlisted as a candidate.
Seems like the best choice I've seen so far. It is interesting to
contemplate how other Java interfaces might be different if javax.service
had been in place first.
Actually, I would argue that even if Avalon Framework is not accepted, it is
a safe bet to use Avalon's programming approach. Because whatever is
adopted, post-JSR 111 Phoenix should be able to support both A-F and JSR 111
objects.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>>>interface MailetContext
>>>{
>>> org.apache.avalon.framework.logger.Logger getLogger();
>>>
>>>
>>-1 , breaks IoC.
>>
>>
>
>Might surprise you to know that I agree. However, it follows the current
>patterns used in the Mailet API (borrowed from the Servlet API), so I put it
>out in code for people to discuss.
>
>
Agree? Great, please go the final couple of inches dude then :-)
>>>interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>>>
>>>
>>-1 , breaks SoC.
>>
>>
>
>You prefer to keep interfaces clean, and compose on a base class, like:
>
> class AbstractMailet
> implements Mailet,
> org.apache.avalon.framework.logger.LogEnabled
>
>instead. The container has to inspect the Mailet, since it does not know if
>a Mailet implements LogEnabled. IF you have a container with that
>capability, it is an appealing construct.
>
I cannot imagine *any* container written in Java that does not have the
capability to do instanceof. It is probably a set-once concept. Please
explain to me your scenario.
>As you must have noted, there seems to be a great deal of resistance to the
>Avalon-ization of the Mailet API.
>
From some but not all quarters.
>That seems to be the real issue to
>address. If these patterns were embedded in javax.frameworks.*, I doubt
>that we'd be having this part of the discussion.
>
JSR 111? Hmnm, let me see, Avalon's Framework is shortlisted as a
candidate.
You gunna vote for JDK1.4 logging? I thought not.
- Paul.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
> >interface MailetContext
> >{
> > org.apache.avalon.framework.logger.Logger getLogger();
> -1 , breaks IoC.
Might surprise you to know that I agree. However, it follows the current
patterns used in the Mailet API (borrowed from the Servlet API), so I put it
out in code for people to discuss.
> > interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
> -1 , breaks SoC.
You prefer to keep interfaces clean, and compose on a base class, like:
class AbstractMailet
implements Mailet,
org.apache.avalon.framework.logger.LogEnabled
instead. The container has to inspect the Mailet, since it does not know if
a Mailet implements LogEnabled. IF you have a container with that
capability, it is an appealing construct.
As you must have noted, there seems to be a great deal of resistance to the
Avalon-ization of the Mailet API. That seems to be the real issue to
address. If these patterns were embedded in javax.frameworks.*, I doubt
that we'd be having this part of the discussion.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
Noel,
>interface MailetContext
>{
> org.apache.avalon.framework.logger.Logger getLogger();
>
>
>
>
-1 , breaks IoC.
>Alternative would be to break with the Mailet v1 API entirely, and go with:
>
> interface Mailet extends org.apache.avalon.framework.logger.LogEnabled
>
>
-1 , breaks SoC.
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
> An individual changing their mind on a subject or even moving
> slightly can be a good thing.
I do not believe otherwise! It was just at a point where I felt I needed a
scorecard and a program, so I thought (and appear to have been right) that
applying the rigor of a code definition would help to clarify positions.
> >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'
specification == Servlets
platform == Tomcat, Weblogic, JRun, et al
specification == Mailets
platform == James, "WebOvoid Mail", "JWalk", YAJMail
One argument seems to be "don't tie the Mailet API to the James
implementation", thus the only packages permissible are mailets, JavaMail
and core java. Your argument is that the Avalon Frameworks should be viewed
on equal footing with javax.* packages.
Based upon some of the statements made surrounding JSR 111, it seems clear
that over time there will be significant refactoring to take advantage of
improvements JSR 111 allows to interface design and evolution.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
Danny,
>>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 ;-)
>>
>>
>
>Thank you Paul,
>I'm not "flip-flopping" I'm modifying and refining my own opinion based upon
>a discussion of the issues with other interested people.
>
>I have reduced my oposition to dependance on a.f and increased my resistance
>to providing sophistcated logging based upon consideration of the opinions
>expressed on this list.
>
>
Yes I know, all is good stuff.... I think ;-)
-ph
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by Danny Angus <da...@apache.org>.
> 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 ;-)
Thank you Paul,
I'm not "flip-flopping" I'm modifying and refining my own opinion based upon
a discussion of the issues with other interested people.
I have reduced my oposition to dependance on a.f and increased my resistance
to providing sophistcated logging based upon consideration of the opinions
expressed on this list.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [Mailet API] Logging Proposal
Posted by Paul Hammant <Pa...@yahoo.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by "Noel J. Bergman" <no...@devtech.com>.
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().
> 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, 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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [Mailet API] Logging Proposal
Posted by Danny Angus <da...@apache.org>.
for reasons already fully discussed elsewhere..
org.apache.avalon.framework.logger.Logger getLogger();
-1
> -----Original Message-----
> From: Noel J. Bergman [mailto:noel@devtech.com]
> Sent: 10 June 2002 20:11
> To: James-Dev Mailing List
> Subject: [Mailet API] Logging Proposal
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>