[infinispan-dev] configuration limitations

[Mircea Markus]

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 at infinispan.org>
> To: "infinispan -Dev List" <infinispan-dev at lists.jboss.org>
> 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 at redhat.com> 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev