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