[infinispan-dev] configuration limitations

Sanne Grinovero sanne at infinispan.org
Tue Mar 6 06:22:55 EST 2012


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



More information about the infinispan-dev mailing list