Adam, > > To achieve this end, I'd like a Mailet API that either uses or copies in > > another package the equivalents of the Contextualizable, Composable, > > Configurable, Initializable, and Disposable interfaces. I'll leave the > > logging question alone for the moment. I don't think we need any of the > > other phases of the Avalon Framework lifecycle (Startable, > > Reconfigurable, etc.). So I don't think the Mailet API should be a full > > Avalon Framework container. > > Avoiding using Avalon Framework in the Mailet API is a good plan, I feel. > The > API already has equivalents to most of the lifecycle interfaces you list > above:
Well, not really. That's one of the reasons everyone want to revamp the API. First off, there is the logging issue. Just search the archives for the relevant discussions. > * Mailet.init() and destroy() give you Initializable and Disposable. True. Though the contracts for these aren't quite as strict as their Avalon equivalents. Especially since init() isn't actually in the Mailet API. But these details can be addressed when the API is being hammered out. > * MailContext.getAttribute() gives you Contextualizable (as do the other > get > methods on MailContext). Here's where we'd start to disagree. See some of the discussion on Avalon-dev about what precisely is involved in defining a context. Just having a context that's a glorified hash map doesn't buy us all that much. This is one area I'd like to see addressed by any API/framework we throw together. > * Composable can be done with a simple lookup method on MailetContext: > Object getService( String roleName ); > or, perhaps better: > Object getService( Class serviceInterface ); This I don't like. The component lookup should be a part of the Mailet interface, and separate from the context. For basically the same reasons the two are separate in the Avalon interfaces. They are conceptually different. > * Configurable could be done using MailetConfig's init parameter methods. > Some way of getting at structured config would be better. It doesn't > necessarily have to be done via MailetConfig. A good approach might be to > configure the mailets (and maybe the matchers, too) using a > reflection/javabean based scheme similar to the way Ant configures its > tasks. I don't think MailetConfig is anywhere near good enough. We need something that is basically identical to the Avalon Configuration interface - something that allows us to pass in structured configuration data and supports defaulting and type validation. Whether the underlying impl (or even the interface class) is the same really isn't the relevant point. The functionality just has to be there. > Just out of interest, how much scope is there in v3 for changing the > Mailet > API, and the way james is partitioned into components? For the API there is tremendous scope for revamp. One of the stated goals for v3 is a new version of the Mailet API. Input is welcomed. :) As far as repartitioning James component-wise, I haven't heard much discussion of this aside from my comments about RemoteDelivery. I'm sure we'd be open to discuss, although I don't think anyone wants to rewrite everything from scratch. So the reaction to a repartitioning request would likely depend on the stated goals as well as the amount of effort involved. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
