[infinispan-dev] configuration limitations

[Manik Surtani]

Excellent, thanks Galder.

On 12 Mar 2012, at 04:38, Galder Zamarreño wrote:

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

--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani

Lead, Infinispan
http://www.infinispan.org