http://jira.jboss.com/jira/browse/JBCACHE-840 Background: All junit tests should have a system property (with a default if the system property is not defined) to use a certain JGroups protocol stack. Thus, for example, we can run whole JBC testsuite with Jgroups tcp stack. We should have multiple tests targets that run testsuite with tcp,udp, and other supported protocols. Current state of affairs: All our non-local mode unit tests use configuration files defined in META-INF directory. We use half a dozen configuration files such as replSync-service.xml, replAsync-service.xml, replSync-passivation-service.xml and so on. It is hard to keep track of all these configuration files and coordinate that all of them have the same Jgroups configuration element. Thus implementation of JBCACHE-840 becomes almost impossible. Solution: 1) Use only replSync-service.xml and replAsync-service.xml Having all our non-local tests rely on these two files allows us to have a strong guarantee that all non-local tests pass with these two specific configuration files. It also constraints all non-local test to only two files. 2) Remove use of other sync and async configuration files In some tests we use variation of replSync-service.xml and replAsync-service.xml that have additional configuration elements such as passivation, eviction etc. Use of these configuration files can be supplemented by use of replSync-service.xml and replAsync-service.xml with addition of programmatic injection of eviction, passivation and other elements during test setup. 3) Add tests targets for non udp jgroups configs Having 1) and 2) completed allows us to modify JGroups stack element in replSync-service.xml and replAsync-service.xml and run the entire test suite with a specific JGroups protocol stack such as tcp. We can modify all our test targets to include specific parameter indicating JGroups stack to be used (i.e udp|tcp) Based on this parameter we can create specific replSync-service.xml and replAsync-service.xml prior to execution of any test build target. Do you guys have some comments, suggestions and such? Regards, Vladimir