james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Darrell DeBoer <darr...@apache.org>
Subject Re: [Mailet API] Logging Proposal
Date Tue, 11 Jun 2002 12:11:32 GMT
On Tue, 11 Jun 2002 15:38, Noel J. Bergman wrote:
> Now you just need to convince people with voting rights.  ;-)
> 	--- Noel

Ummm, I'd be one of those I guess, although I'd be extremely reluctant to use 
it, since I've been off in Myrmidon (Ant2 proposal) for some time.

I read this thread with interest, and I have a few comments.

* I pretty much agree with Danny and Serge that the Mailet API itself 
shouldn't have any direct dependencies on the Avalon Framework, if possible.

* Any Mailet written solely against the Mailet API will function perfectly in 
James, the Reference implementation of a Mailet container.

* This doesn't mean that a particular Mailet shouldn't be able to use Avalon 
Framework interfaces, in a container that supports those interfaces. eg 
LogEnabled: I think that LogEnabled provides a clean, implementation neutral 
way of getting a Logger from the Mailet container, but some mailets may 
choose other ways. However, in using LogEnabled the Mailet author is saying:
     "this mailet can be used in any container which supports both the Mailet 
API and the Avalon LogEnabled contract".

* I believe that James should provide support for a relevant subset of Avalon 
contracts, maybe just LogEnabled, or any others that seem very useful. This 
would be value-added behaviour of James the Mailet container, providing 
additional services (beyond the Mailet API) to any hosted Mailets. 

* If a Mailet writer wants their *LogEnabled* Mailet to work in a 
non-avalonized container, they would need to ensure that they provide a 
default Logger themselves in the case that "enableLogging(Logger logger)" 
isn't called.

* The big question is whether the core James mailets use LogEnabled. I say 
"why not?". After all, these are just mailet implementations, and not part of 
the MailetAPI itself. Maybe we can provide an adapter which can be used to 
run LogEnabled Mailets in non-avalonized containers, but I wouldn't be 
surprised if *all* Mailet containers end up supporting LogEnabled directly. 

I guess the main point is that we can have the Mailet API completely 
independent of Avalon-Framework, yet still *support* Avalon-Framework 
contracts in James, the Mailet Container. This keeps the Mailet API clean, 
and hopefully future-resistant, while allowing us to reuse some of the 
concepts and strategies which have proven so useful in Avalon.


btw: I saw CascadingException mentioned somewhere - as in MailetExceptions 
should extend it. I don't think this is necessary. In Myrmidon we use 
reflection to determine if a particular exception has a getCause() method, 
and handle as a Cascading exception if it does. This allows us to properly 
handle any exceptions which follow this (or similar) pattern. Once again, 
this is a value-added service which James *could* provide - but a Mailet 
container which didn't would just treat cascading exceptions as regular old 
exceptions (and ignore the nested ones).

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message