I'm gonna try to tackle this as part of https://issues.jboss.org/browse/ISPN-1367
Thx On Mar 6, 2012, at 11:34 AM, Mircea Markus wrote: > 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 -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
