The current discussion is valuable, but isn't converging and some of it borders on silly religious debate. Let's clarify a few points, and establish a direction.
-- much of JAMES is ALREADY independent of Avalon. Only a few major components care about Avalon, and those are not too hard to convert. There are several different notions of container in JAMES, and that is as it should be, actually. -- services run in an application container. These are the main SMTP, POP3, IMAP, NNTP, etc., services. The nature of how those are deployed should NOT impact the mailet container. The mailet container is intended to be a portable container installable in other applications. -- reuse of existing J2EE design patterns is a good thing. J2EE is very much based upon containers and components. Servlets, JSPs, Portlets, EJBs, etc., are all container managed components. Proper reuse of existing patterns is reasonable. Mailets are quite similar, and are managed by the mailet container. Our transport services and mailets can use dependency injection and also resource lookup. Both are both valuable and neccessary. Let's avoid extremist philosophical rhetoric. Consider the basic approach with J2EE. Standard things are injected by lifecyle methods (e.g., ServletConfig). JNDI is also available because these are general architectures. I've had experience with another approach, where the component was given a context from which it could do an constrained lookup, but that is a poor and non-standard approach, and the next generation of that product has gone with JNDI as the standard mechanism. Whether we go with constructors to inject dependencies, or follow the more flexible approach of using lifecycle methods isn't that big a deal. Personally, I strongly favor lifecycle methods for a variety of technical reasons. In fact, I have a few that I consider to weigh heavily against constructor injection, but the exposed surface of the components should be so small compared to internals that we should be able to fix things in mid-stream if we go down the wrong route. In short, I tend to agree with Mike Heath, and add JNDI as well where that is appropriate. --- Noel --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]