On Sat, 23 Nov 2002 04:57 pm, Peter M. Goldstein wrote: > 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.
I agree that the current API is missing some important pieces, and other pieces need to be reworked. My point (which, re-reading what I wrote, wasn't clear at all) was this: The mailet API is actually quite good. With some tidying up, I think, it can solve the problem just as well as one based on Avalon framework or a clone. Not that I think a solution based on A-F is bad. Far from it. Using A-F, the solution becomes easy: Mailets and matchers are avalon components. Mailet interface has a single service() method, Matcher interface has a single match() method. Done :) On the other hand, I feel that a Mailet API based on a clone of A-F is kinda pointless. Why bother? A-F is proven, documented, implemented and all that good stuff. The james specific clone is not. I can understand the reluctance to add a dependency on something other than javax.*. Just seems a little misplaced. A-F isn't going to disappear, change its license, etc, any time soon. The avalon folk seem to take backwards compatibility seriously, as well. > > * 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. It's not? It's on the Mailet and Matcher interfaces. Are you referring to GenericMailet.init() where the current crop of mailets do their initialisation? I don't see GenericMailet/GenericMatcher as part of the API - they're just convenience classes. > > * 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. Absolutely. I think we're saying the same thing here. Domain-specific context methods are necessary, as is a catch-all get( name ) method. But MailContext already has these methods. Maybe some of them could be renamed, maybe some added, maybe a couple removed. > > * 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. Yep. That's why I suggested adding a getService() method, instead of suggesting overloading, say, getAttribute(). The mailet API does not necessarily have to split up resource delivery the same way that A-F does. Let's take a step back. As I see it, the mailet container has to deliver 4 types of resources to mailets: - A logging service. - Configuration for the mailet. - Environmental information and passive resources. Includes well-defined container independent resources, and container specific resources. - Active services. Includes both well-defined container independent services (arguably the logging service could fit here), and container specific services. Obviously a heap of ways to do this: Push: - Use A-F: LogEnable, Contextualize, Compose, Configure. - Clone A-F, with a separate marker interface for each resource group. Each interface would contain a single setter method. - Add a setter method to the Mailet interface for each resource group: setLogger( logger ), setContext( mailetcontext ), setServices( servicelookup ), setConfiguration( config ). - Use reflection to locate the setter methods on the mailet. Pull: - Add a getter method to the MailetContext for each group of resources: getLogger(), getAttributes(), getConfig(), getServices(). Deliver the MailetContext to the mailet using init( MailetContext ). - As above, but flatten some or all of the lookup interfaces onto MailetContext. Eg replace context.getAttributes().get( name ) with context.getAttribute( name ). Personally, I prefer the A-F or 'flattened pull' approaches. > > * 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. Again, the mailet API does not necessarily have to deliver configuration in the same way that A-F does. Handing over a tree of config is a good approach. An equally good alternative is to deliver config using reflection and setX() and addX() methods. > > 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. :) Excellent. See above, then :) -- Adam -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
