Noel et al,
> > Unfortunately [embedding] is a limitation of the Avalon framework > > Actually, Merlin and Fortress are embeddable or going that way, so I don't > view that as an issue. Remember, Cocoon embeds inside of Tomcat. Agreed. Embedded containers are one of the big themes on the Avalon-dev list, third on the list after discord and sarcasm. :) Moreover, there is an EJB container that is embeddable inside Phoenix, there is an active effort to embed Tomcat inside Phoenix, etc. So not only is the idea to embed Avalon framework containers inside other containers, but also to embed other types of containers (EJBs, servlets, etc.) inside Avalon framework containers. It's almost Escher-esque. > I don't think that the current version of James gets down to quite as trim > a > package as we can build a mailet container, but that doesn't mean that we > need a separate codebase. Let's just accept as a request for v3 that > being > able to embed a mailet container is a good thing, and see where that takes > us. I agree. But my approach would be to delegate the embeddedness to our Avalon framework container. There should be nothing in the Mailet API that prohibits such embeddeding, but I don't think we need to re-invent the wheel. Merlin/Fortress/Avalon Container++ can handle this. > Personally, I have some ideas but we'll see how this falls out. I will > point out that you appear to be leaning towards making Avalon a part of > even > embedded Mailet Containers. I'm curious to see how Danny and Peter > respond. > And, of course, if I am wrong please clarify. I actually (as I've mentioned before) really like the Avalon framework lifecycle. That said, I don't see any reason that we should build rings within rings. With the theme of not reinventing the wheel, I don't think we need to re-implement Phoenix inside Phoenix. The mailet container doesn't need to support components of arbitrary complexity, provided it has an effective API for getting other components in the larger container (Avalon or another type of container). For example, the RemoteDelivery mailet could be rewritten as a more lightweight, single threaded class that passes the mail to a RemoteDelivery component that is managed directly by Phoenix. This would allow the mailet to be kept nice and simple, the RemoteDelivery component would be made easily pluggable, and the component could take advantage of features of the container (i.e. JMX) that we might not want to expose directly through the Mailet API. This approach seems very COP to me. 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. But after 2.1 goes out we'll see what Danny's got written up and start from there. If it provides the same basic functionality as the Avalon lifecycle phases above, that would probably be ok with me. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
