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.
--
ciao,
Daz
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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
