I still think it is highly desirable to allow logging at more than one level, i.e. the typical error, warn, info and debug. Having followed the discussion with varying degrees of interest :), what is wrong with having the corresponding methods exposed via the MailetContext? There's no need to expose the actual logging mechanism to the mailets themselves, no need to create a logging fa�ade and no need to expose Avalon Framework logging interfaces to the mailets.
Regards Steve > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Monday, June 10, 2002 12:11 PM > To: James-Dev Mailing List > 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: > <mailto:james-dev-> [EMAIL PROTECTED]> > For > additional commands, > e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
