Serge Knystautas wrote:
> 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
>>
>
> -1 for Avalon dependency (danny's spoken on this)
AFAIK he has not ruled out Avalon dependency.
You cannot -1 without a sound reason.
"Please comment with specific changes (or even rewrites), so we can keep the
discussion concrete."
Thank you Serge for your concreteness.
> , 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")).
Ok, so you mean you need logging, but feel uneasy to use an api you didn't
write?
Ok, then I see two solutions, as I said before:
1. make mailet dependent on Avalon, and have it have all the methods it
needs to make a complete mail server.
2. stay on the core and put in no logging, no context, no parameters.
The downside of (2) is that since logging, etc... are *always* needed, every
implementor will put in his, and you can say goodbye to interoperability.
*This* is a solid reason.
I don't think that "I wanna remain clean from Avalon" is a technical reason.
Thus, your -1 is not valid.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
