Peter, >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. > Well we did deprecate the Component interface many many months ago. We were not very good at jkeeping you folks on board and in step :-(
>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. > Actually it happened in Avalon-Framework which has had a few releases since the original deprecation. >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. > I understand your anger. It is our fault for not presuading you folks for keeping in step with our careful depecation scehdule in Avalon-Framework and then Avalon-Cornerstone. >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. > With the greatest of respect, your users are far smaller in number that those to say Servlet (or those to say jdbc - a real balls-up of backwards compatability) >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. > I myself, might devise an API that has a custom 'lifecyle' methods for mailets :- MailStoreAware [ which has setMailStore(MailStore mailStore) ] DataSourceSelectorAware [ which has setDataSourceSelector(DataSourceSelector selector) ] The container for mailets calls those method after instantiation. Anyway, that is abig subject that embraces many IoC concerns, and definately breaks back-compatability. >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? > Could do. Stephen offers to maintain the forked Cornerstone. >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? > I have pointed out that the wrapper solution, though clever, will not work for two of the mailets in James codebase ( JDBCAlias and JDBCListserv ). So... v) Have a JamesDataSourceSelector that wraps the actual DataSourceSelector implementation and additonally implements Component. It will be a hand-coded proxy of course. - Paul > >--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]> > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
