Noel , _Please_ Avalon-Framework not Avalon.
You're wrong too....you mention 'Avalon object' (again context is misleading) yet the LogEnabled.java is an interface. For alternate containers, it would return an alternate-conatiner object. For JAMES it would likely return a JAMES object, that might delgate thru to the A-F LogEnabled obj passed to it by the Avalon-Phoenix container..... You are going to end up with an undeniable knock-off of LogEnabled....... - Paul >Paul, > >I believe that Danny's point is this: "Because other applications which use >mailets to process mail might not have or want avalon ..." > >Therefore, he wants an org.apache.mailet.Logger interface, even if the >implementation of MailetContext.getLogger() returns an Avalon object. The >Mailet Logger API might not differ from the Avalon Logger API, other than to >effectively put it in the "right" package. So the James implementation can >happily use Avalon, since James is an Avalon applcation, but mailets should >not have to import anything other than org.apache.mailets.*, java.* and >javax.mail.* in order to access the Mailet API. > >The Mailet API definition will be interesting later, because such things as >a mailing list mailet want to be able to control the underly mail platform, >not just manipulate message content. > > --- Noel > >-----Original Message----- >From: Paul Hammant [mailto:[EMAIL PROTECTED]] >Sent: Saturday, June 08, 2002 17:14 >To: James Developers List >Subject: Re: Finer Logging Control for Mailets/Matchers > > >Danny, > > > >>>I agree ... so please explain exactly how this "wrapper interface" would >>>differ from the logger facade in org.apache.avalon.framework.logger. Are >>>you simply saying that you want to put a facade over their facade so that >>>the naming space is part of the Mailet API instead of Avalon? >>> >>> >>> >>> >>Yes, in a nutshell. >>Because other applications which use mailets to process mail might not have >>or want avalon or log4j or whatever. >> >> >> >Avalon is a project. I think you are referring to Logkit. You will find >that there is a truly excellent abstraction called LogEnabled in the >Avalon-Framework interfaces. We have already implementations for this >that route method invocations to Log4J, LogKit, JDK1.4 logging, The >console and null: This is a really great API for an implementation >neutral API to implicate. > >The Avalon-Phoenix container patches such calls thru to LogKit. The >maillet API being evolved naturally will not name Avalon-Phoenix as a >pre-requisite. JAMES (the reference impl of the maillet API) sits on >Phoenix. > >- Paul > > > >-- >To unsubscribe, e-mail: <mailto:[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]>
