Danny, >>Err, actually I am advocating closer binding with Avalon-Framework >>interfaces. >> >> > >I'd rather see the mailet API developed completely independant of any >dependancies at all, apart from Java Mail. >It would then be up to James' implementation to conform to avalon design >imperatives, and benefit accordingly. > > Yes, a maillet may impl all, any or none of the Avalon-Framework methods. James (the container) recognises that is it instantiates maillets and decorates them accorting to lifecycle concepts. What I'm anxious for you folks to avoid is the duplication of things illustrated by Avalon-Framework.
>I'd like to see mailet being used by people and products with no connection >to James at all, and no reason for them to even know about James. > > Multiple implementation of maillet aware container. Agree. - Paul -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
