All,
Ok, we have a problem. Switch to Serviceable or not? How to do so? One option is to switch to Serviceable completely. Remove the ComponentManager from the Mailet API and replace it with a ServiceManager. One for one replacement. But this seems to miss the whole point of deprecating. The point of deprecating an interface, method, etc. is precisely to give warning that you're may make a change that breaks compatibility in any general release following the one in which the deprecated marker was introduced. This allows you to have consumers of your API, framework, libraries, what-have-you migrate in an orderly fashion. As far as I'm concerned, the Avalon folk made a mistake in removing Component from a number of classes. They introduced deprecated tags and changed the API implementations affected, all within one release. Thus the fact that "Component" is marked deprecated is largely irrelevant - the implementations are already not backwards compatible. So they screwed up. The fact that this stuff is all central to the Avalon lifecycle just makes it more serious. The fact that keeping a marker interface on all the relevant implementations for one more major release would've alleviated this problem and made us all happy campers just makes it sillier. James is an Avalon consumer, so we have to live with all of this. However James is also the container for another public API, and we have a responsibility to mitigate the effects on users. That is, we have to be responsible in our use of deprecation. We cannot simply tell our users - we're going to do a release in a month and, btw, we changed that core API with little to no discussion. The assumption that our users will be happy to rewrite, recompile, redeploy, and retest their mailets to deal with this API change is a bit optimistic in my mind. Let me be clear - I really don't like the way the component manager is obtained by mailets. It violates COP principles, etc. But all that is irrelevant. We have an obligation to our user base to notify them of (and preferably discuss with them) changes with a decent warning period. Moreover, we have an obligation to discuss among ourselves how we want to expose Avalon functionality in the Mailet API (a contentious topic, to be sure). Personally, I'm not nuts about committing to exposing ServiceManager through the Mailet API in the same fashion as we've exposed ComponentManager in the past. Ok, so that's the argument for preserving as much backwards compatibility as possible. So why don't we just leave the code as is, compiling and running against frozen versions of these libraries/containers from a particular date? Because - if we don't keep up with the current code base, James will find itself with a real problem - we won't get Avalon Framework, Cornerstone, Excalibur, or Phoenix bug fixes. Those bug fixes have a marked effect on James. For example, just today there was a quick discussion on james-user about a problem that had been addressed (by Steve I might add) in Cornerstone and resolved an observed problem in James. We need those changes. While there's been a lot of discussion about the idea of running James in other containers, etc. I feel pretty safe saying the following: i) James will depend on the Avalon lifecycle framework and on the Cornerstone and Excalibur code bases for the near future. ii) The primary deployment (distributed binaries, documented configuration, etc.) of James will be inside a Phoenix container for the near future. Right now we're running on a pre-release version of Phoenix, and there's actually been a discussion on Avalon-dev about keeping us on a special forked version of Cornerstone. We need to do the Serviceable switchover to continue to keep up with our third party provided software. As far as I'm concerned, that makes some sort of switchover effectively mandatory. So that leaves us in search of a third option. My suggestion would be the following: i) Keep everything in James labeled Component. As discussed, this is just a deprecated marker instance. This doesn't cost us anything. ii) Change the ComponentManager in the Mailet API to be an AdaptingComponentManager that wraps a ServiceManager. Document this feature of the API as deprecated in the documentation. Describe the issue with Cornerstone in the documentation. Document which of the standard blocks will not be accessible. iii) Add a ServiceManager to the Mailet API in an identical fashion as the ComponentManager. This is necessary to expose those darn Cornerstone implementations to mailets. Mark it as immediately deprecated, with a note that mailets designed for this revision that use this feature will not be compatible with 2.2. This will give us time to have the relevant discussion without making it necessary to push our next release even farther out. iv) Update all James core code (service implementations, mailets we store in CVS, etc.) to use Serviceable rather than Composable and to employ the ServiceManager rather than the ComponentManager. That's my suggestion. Thoughts? --Peter > -----Original Message----- > From: Steve Short [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 1:13 PM > To: James Developers List > Subject: RE: [PATCH] Replace Components with Services > > I agree. If James has to keep any references to Component then we > needn't bother doing any changes at all. Component is currently > deprecated and presumably it will be remove entirely in future release. > > Steve > > > -----Original Message----- > > From: Paul Hammant [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, September 24, 2002 1:00 PM > > To: James Developers List > > Subject: Re: [PATCH] Replace Components with Services > > > > > > Peter, > > > > >As we've discussed before on the james-dev list, it's a little more > > >indepth than this patch addresses. > > > > > > > > > > > >i) The Mailet API is to remain invariant > > - that is, > > >mailets must be able to access the same components as > > previously using > > >the component manager that was provided to them through the > > >MailetContext. > > > > > >ii) Point (i) requires that all James services > > >continue to implement the Component marker interface. No > > biggie, it's > > >just a marker interface > > > > > True, but it has been eliminated from Cornerstone in Apache > > HEAD CVS. > > > > >iii) Point (i) also requires that we use an > > >AdaptingComponentManager (sic?) to wrap the ServiceManager > > and provide > > >components to the mailets. > > > > > > > > (wrapping) Perfectly possible. but ..... > > > > Take init() from org.apache.james.transport.mailets.ToRepository > > > > ComponentManager compMgr = > > (ComponentManager)getMailetContext().getAttribute(Constants.AV > ALON_COMPONENT_MANAGER); > > try { > > MailStore mailstore = (MailStore) > > compMgr.lookup("org.apache.james.services.MailStore"); > > > > 1) If MailStore extends Component this will work. > > > > Well it does not anymore, it extends Cornerstone's store, but > > you have > > the source for MailStore, so can to "extends Store, Component". > > > > 2) If all ComponentManager looked up things are in your > > codebase, then > > you have a strategy in (1). > > > > Well, that is not true, JDBCAlias (and JDBCListserv) returns > > DataSourceSelector on lookup, which is in Cornerstone's CVS. > > You could > > invent JamesDataSourceSelector which wraps the Cornerstone > > one and adds > > an impl of Component, then it it will work fine, but it changes the > > JDBCAlias source, which breaks the backwads compatible directive. > > > > >If it weren't for these little issues, we'd probably have > > gotten to it > > >a while back. If you'd like, you can update the patch to > > address these > > >issues and resubmit. Thanks. > > > > > > > > The patch can be fixed as per the strategy outlines in (1) and (2) > > above. It will mean that the DataSourceSelector usage will end, but > > that is only two mailets in your codebase. > > > > If I were you I'd decomission ComponentManager completely for > > the sake > > of ServiceManager (Component for Object, and Composable for > > Serviceable). It is a brave step and does break backwars > > compatability, > > but it is very nearly a word replacement issue for the user > > community. > > If James mailets were distributed as shrink wrapped, then > > you'd have a > > problem, but they are not. > > > > You choice, I'm an honarary committer here (my capacity is limited to > > Phoenix related issues). > > > > Regards, > > > > - Paul > > > > > > > > > > -- > > 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]>
