[jbosscache-dev] JBCACHE-840

[Manik Surtani]

On 2 Jan 2007, at 18:16, Vladimir Blagojevic wrote:

> 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.
>

I presume you mean just use one file.   Setting cache mode from sync  
to async should be a part of the test's setup() method rather than  
the cfg file.

>
> 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.

+1.

>
>
> 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.
>

+1 again.  I think we need to ship with the different configs as  
examples, but for the tests, we should use /etc/META-INF/unit-test/ 
unit-test-cache-service.xml which then gets further customised in the  
test setUp() methods.  And

We would then also need a separate unit test to test all of the  
'example' configs to make sure they're all valid too, but this is a  
side issue.

>
>
> Do you guys have some comments, suggestions and such?
>
>
>
> Regards,
> Vladimir
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev