[infinispan-dev] configuration limitations

[Galder Zamarreño]

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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache