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.
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. 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. Regards Steve > -----Original Message----- > From: Peter M. Goldstein [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, September 24, 2002 3:44 PM > To: 'James Developers List' > Subject: RE: [PATCH] Replace Components with Services > > > > Paul, > > > 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) > > I absolutely agree with you. But it doesn't really matter. > We haven't given any notice to our user base, no matter how > small that base might be. That's the problem. > > Part of evolving into an enterprise piece of software is > being attentive to the user base, both at the beginning and > as it grows. That means you don't do things like this. > Otherwise you have trouble getting to the point where you > carry a large customer base with you. > > > I myself, might devise an API that has a custom 'lifecyle' > methods for > > mailets :- > ... > > Anyway, that is abig subject that embraces many IoC concerns, and > > definately breaks back-compatability. > > Exactly. It's a big subject, requiring a lot of discussion. > And I think it's clear that the James developers don't have a > consensus on this one (see the Mailet logging discussion for > reference). This will require lots of discussion and time - > IMHO we shouldn't do this before 2.2. > > > >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. > > Personally I'd -1 this one. For all the reasons I list. > > > I have pointed out that the wrapper solution, though > clever, will not > > work for two of the mailets in James codebase ( JDBCAlias and > > JDBCListserv ). > > > > This is taken care of by (iii) and (iv). We can add (v), but > my concern is custom written mailets, not core code base. As > (iii) states, the ServiceManager is exposed analogously to > the component manager. As (iv) states, all code stored in > the James CVS would be migrated. That includes the JDBCAlias > and JDBCListserv. So (v) is unnecessary to deal with these > mailets. It's only necessary if custom mailets are using the > DataSourceSelector. Not necessarily a bad idea, just doesn't > solve the generic problem. > > --Peter > > > > > > -- > To unsubscribe, e-mail: > <mailto:james-dev-> [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]>
