Re: [infinispan-dev] configuration limitations

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" <sanne(a)infinispan.org&gt; > To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org&gt; > 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 <mmarkus(a)redhat.com&gt; 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 >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev