[jbosscache-dev] JBCACHE-840

[Vladimir Blagojevic]

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