Please consider this my -1 to replacing ComponentManager in the Mailet API with ServiceManager as a long term approach.
There have been extensive discussions on this list about the coupling between the Mailet API and Avalon. How extensive should this coupling be, what form should it take? For my part, I don't really have a tremendous objection to a tighter coupling between Avalon and the Mailet API. I know that some do, because they want to see the Mailet API become a server-independent standard. I respect that opinion, but it's not the reason I'm voting against this as a long term proposal. I'm interested in James as an enterprise quality mail server, not in the Mailet API in the abstract. If the mailet API were to incorporate some subset of the Avalon lifecycle, I'd have no objection in principle. I do object however to an attempt to slip things in the back door. The current situation is the worst of both worlds. We're tightly coupled to the Avalon lifecycle framework (see the current situation), but gain none of its benefits. There is no ordered lifecycle, no well defined series of events. There isn't even a wrapper method for the MailetContext to ensure that when we get the ComponentManager / ServiceManager we're actually getting a ComponentManager / ServiceManager object because that would introduce Avalon classes into the Mailet API. That's supposedly a guarantee of the container, but it can't be a real guarantee because not every Mailet container is necessarily an Avalon container. So these mailets aren't really portable even though their interfaces all say they are. Arrgh. But we don't have any Avalon interfaces in our API, so we're Avalon independent (wink, wink). Double arrgh. For a long term solution I see three possibilities: i) Incorporate the Avalon classes into the Mailet API - there is strong objection to this and it ties us to Avalon ii) Incorporate some other set of classes that provide much of this functionality (i.e. JDK 1.4 for logging) and write adaptors for the relevant Avalon classes - probably incur strong objections, adaptors might be tricky iii) Do it all ourselves, making a more rigorous lifecycle for the mailet and write adaptors for the relevant Avalon classes - probably the least objections from those who want the Mailet API to be independent, adaptors might be tricky Anyway, that's why I'm voting -1 on simply replacing ComponentManager with ServiceManager for the long haul. I understand we may need to do it temporarily. If we do, I want us to commit to coming up with some sort of acceptable solution by a given date/release. Otherwise I'll vote against the change. --Peter > -----Original Message----- > From: Steve Short [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 4:10 PM > To: James Developers List > Subject: RE: [PATCH] Replace Components with Services > > Yes - replace ComponentManager with SystemManager. I do not think is as > big a deal as you do. > > Steve > > > -----Original Message----- > > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, September 24, 2002 4:05 PM > > To: 'James Developers List' > > Subject: RE: [PATCH] Replace Components with Services > > > > > > > > Steve, > > > > > It is an unfortunate situation, but I think the path that will cause > > the > > > least pain now and in the future is to bite the bullet and do it. > > There > > > aren't too many mailets that use a ComponentManager / ServiceManager > > and > > > for those the code change is trivial. > > > > But that's exactly the question - do what? Replace > > ComponentManager with ServiceManager? Is this our permanent > > solution (very -1)? If not, how do we present it to our user > > base? When do we expect to have a permanent solution? > > > > > Let's not get into forked Cornerstone or being tied to prehistoric > > > releases of Avalon packages, both of which will just lead > > to more and > > > more compatibility problems. James needs to be able to move up to > > newer > > > releases of these packages as easily as possible. > > > > Absolutely agree. > > > > > As far as backwards compatibility is concerned, this is partially > > blown > > > already with the enabled flag required in config files so existing > > > config files will no longer work. Admittedly this is much > > easier to > > > fix. > > > > There is a huge difference here. Basically we can (and > > should) write some simple XML transform code to change the > > config file as necessary. Even if we don't do this, any > > administrator can be instructed to do minor adjustments to > > their config file. > > > > Changing APIs is an entirely different order of magnitude. > > > > --Peter > > > > > > > > -- > > To unsubscribe, e-mail: > > <mailto:james-dev-> [EMAIL PROTECTED]> > > For > > additional commands, > > e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > -- > To unsubscribe, e-mail: <mailto:james-dev- > [EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:james-dev- > [EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
