11:46 p.m.
Hey all,
Possibly the first of a few emails with questions on this JIRA and understanding the state
of things since I haven't been looking at code on this project in a long, long time.
This JIRA (ISPN-2463) is essentially about cleaning up the use of the configuration API -
i.e. not using org.infinispan.config.Configuration and using
org.infinispan.configuration.cache.Configuration - and removing a lot of calls to the
deprecated Configuration class within the test-suite. Should the methods that make calls
to the now deprecated Configuration class be removed in the abstract test classes such as
MultipleCacheManagersTest? For example, should this method [1] be removed and any other
methods that call it be modified appropriately?
I just wonder if it's something that should be cleaned up properly before any 5.2
CR's happen.
Discuss away, Infinispan gurus.
------------------------
Navin Surtani
Software Engineer
JBoss SET
JBoss EAP
Twitter: @navssurtani
[1] -
https://github.com/infinispan/infinispan/blob/master/core/src/test/java/o...
1 a.m.
On 14.11.2012 06:46, Navin Surtani wrote:
Hey all,
Possibly the first of a few emails with questions on this JIRA and understanding the
state of things since I haven't been looking at code on this project in a long, long
time.
This JIRA (ISPN-2463) is essentially about cleaning up the use of the configuration API -
i.e. not using org.infinispan.config.Configuration and using
org.infinispan.configuration.cache.Configuration - and removing a lot of calls to the
deprecated Configuration class within the test-suite. Should the methods that make calls
to the now deprecated Configuration class be removed in the abstract test classes such as
MultipleCacheManagersTest? For example, should this method [1] be removed and any other
methods that call it be modified appropriately?
In fact beside the test for compatibility of the old api and adaption no
org.infinispan.config stuff should be used in test cases.
When you have migrated all the usages to the current methods, this can
be removed. From time to time I migrate also some test classes in/for 5.2.
ISPN is well tested (yay :-), so the migration is straight forward work.
But be careful, I noticed slighly differences in the defaults used in
the old configuration compared with the new one. For example it may be
needed that you set LockingMode.PESSIMISTIC when tx is used, since the
old config defaults are more or less the same as the current
PESSIMISTIC. The new configuration api defaults using
LockingMode.OPTIMISTIC as default.
8:47 p.m.
Yeah fully aware of some of the changes with the API. That's why I'm trying to be
as careful as I can. I know that some of the defaults aren't the same anymore and also
also you need to be using a different approach in order to configure certain things.
CacheLoaders being one of the big ones where you need to be a little bit more careful in
terms of how you approach the configuration.
------------------------
Navin Surtani
Software Engineer
JBoss SET
JBoss EAP
Twitter: @navssurtani
----- Original Message -----
From: "Thomas Fromm" <tf(a)tfromm.com>
To: "infinispan -Dev List" <infinispan-dev(a)lists.jboss.org>
Sent: Wednesday, November 14, 2012 3:00:06 PM
Subject: Re: [infinispan-dev] ISPN-2463: Removing some deprecated methods within
MultipleCacheManagersTest?
On 14.11.2012 06:46, Navin Surtani wrote:
Hey all,
Possibly the first of a few emails with questions on this JIRA and understanding the
state of things since I haven't been looking at code on this project in a long, long
time.
This JIRA (ISPN-2463) is essentially about cleaning up the use of the configuration API -
i.e. not using org.infinispan.config.Configuration and using
org.infinispan.configuration.cache.Configuration - and removing a lot of calls to the
deprecated Configuration class within the test-suite. Should the methods that make calls
to the now deprecated Configuration class be removed in the abstract test classes such as
MultipleCacheManagersTest? For example, should this method [1] be removed and any other
methods that call it be modified appropriately?
In fact beside the test for compatibility of the old api and adaption no
org.infinispan.config stuff should be used in test cases.
When you have migrated all the usages to the current methods, this can
be removed. From time to time I migrate also some test classes in/for 5.2.
ISPN is well tested (yay :-), so the migration is straight forward work.
But be careful, I noticed slighly differences in the defaults used in
the old configuration compared with the new one. For example it may be
needed that you set LockingMode.PESSIMISTIC when tx is used, since the
old config defaults are more or less the same as the current
PESSIMISTIC. The new configuration api defaults using
LockingMode.OPTIMISTIC as default.
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
4886
days inactive
4887
days old
infinispan-dev@lists.jboss.org
2 comments
2 participants
participants (2)
-
Navin Surtani -
Thomas Fromm