Agreed on almost almost all points: we should still keep some tests using old config till the point we drop them. I don't want to undertake that change *now* simply as a matter of priority: that would most likely delay the release of TO for next week (actully two weeks as I'm off next week) and the solution I can with to solve this problem is very simple.
----- Original Message ----- > From: "Sanne Grinovero" <[email protected]> > To: "infinispan -Dev List" <[email protected]> > Sent: Tuesday, March 6, 2012 11:22:55 AM > Subject: Re: [infinispan-dev] configuration limitations > > It is a massive change as you say, but it should be done as we would > need to drop the old configuration at some point in the future. > > As you say currently the new CFG API delegates to the old one, this > should be changed to work the other way around: the deprecated API > needs to stay for a longer time (see my rant from tonight) but > changed > to delegate the the new one. > > In a second step, so *after* all unit tests verified the legacy > configuration is still working, we should update all tests to use the > new API, and then in version 8.0.CR2 you can drop the legacy > adapters. > > Cheers, > Sanne > > On 6 March 2012 11:07, Mircea Markus <[email protected]> wrote: > > Hi, > > > > Here is config related problem and a suggested solution. > > CloudTM's total order requires some new configuration attributes. > > These attributes should only be added to the new config hierarchy > > and not be present in the deprecated hierarchy. > > > > The problem is that when we build a cache with the *new* > > configuration object, it is internally translated to the old > > configuration object and then passed to the cache. All our > > components use references to old-configs. This doesn't work is my > > scenario, as I don't want the old configuration to be aware of > > total order. I actually don't even want my new classes to depend > > on the old configuration, as it is deprecated. > > > > The proper fix for this is to use new Configuration hierarchy > > internally but that's a massive change. So what I've done is to > > make the old configuration object hold a reference to the new > > configuration. This also helps making the new configuration > > available by @Inject. Any other suggestions? > > > > Cheers > > Mircea > > -- > > Mircea Markus > > twitter.com/mirceamarkus > > > > Sr. Software Engineer, Infinispan > > http://www.infinispan.org > > > > _______________________________________________ > > infinispan-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
