Paul, > > Phoenix, Merline etc are for very fat server components - Mail > > servers, web servers, bean servers etc.
If the mail server were all one component I might agree with you here. But, in the spirit of COP, the mail server is implemented as a series of components. Most of them are pretty lightweight, defined by a few classes. > It is equiv to your guys allowing Mailets to be Serviceable (I know, I > know), and tehy could look up other mailets, but not the core of JAMES > .. the comps/blocks that make JAMES itself. That's not the behavior I believe to be most useful. Aside from the "couple to Avalon interfaces debate" (the whole Serviceable question), there is a more serious issue. Mailets for the most part won't need to interact with other mailets - why would they? Mailets are simple beasties that basically process mail messages. In a similar vein, servlets may need to access other servlets in a servlet container, but just as frequently (if not more frequently) they need access to non-servlety things (data sources, etc.). What mailets will need is to be able to interact with components provided by the server (i.e. database connection managers, dns lookup utilities, thread pool managers, etc.). That's why the Avalon ComponentManager was made available to them in the first place. Thus it would be extremely useful to be able to declare a dependency in a mailet that could be propagated to the enclosing container (in this case Phoenix). That would be very handy. If not, custom mailet builders who want to introduce new dependencies will have to alter the .xinfo file for the mailet container component to declare these dependencies and rebuild a custom binary. I'm not sure any of this dependency declaration is either easy or possible in Phoenix, but it would be very useful. Merlin seems to have pushed more dynamically in this regard, although I haven't given it a detailed once over. In any case, I will say that the kind of complete tier separation that is reflected in the quoted thinking is not going to be the most common/useful case for applications that define additional containers inside Avalon containers. --Peter -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
