Since JBoss Cache 3 is nearly ready to go GA, we are beginning an effort to see if it can be used in JBoss AS 5.0.0.GA. This involves creating a dev branch of the AS and EJB3 and using them to test 3.x versions of JBC and PojoCache, making code modifications as needed.

This page documents how to use the AS and EJB3 testsuites to do this testing. See also AS Clustering Testsuite for background information on the testsuite.

Using the Testsuite

I set up the following directory structure; you can of course do whatever you like; I show this to make the rest easier to understand:

home
++ bes
++++ JBC3_in_AS5
++++++ AS
++++++ EJB3

To check out the AS branch:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS
[bes@besdev AS]$ svn checkout https://svn.jboss.org/repos/jbossas/branches/Branch_JBoss_Cache_3

To check out the EJB3 branch:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/EJB3
[bes@besdev AS]$ svn checkout https://svn.jboss.org/repos/jbossas/projects/ejb3/dev/Branch_JBoss_Cache_3

To build the AS:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/build
[bes@besdev AS]$ ./build.sh

To build the AS testsuite:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh

To build the EJB3 testsuite:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/EJB3/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ mvn install

At this point the hope is there will be no reason to modify any EJB3 code; I just created Branch_JBoss_Cache_3 in EJB3 so we have a stable copy of the EJB3 testsuite to work with. If there is a need to build any other part of EJB3 besides the testsuite module, go to the root of the ejb3 checkout and "mvn install".  The code relevant to JBC is in the "core" module found at the same level as "testsuite".  There is also a "proxy-clustered" module at the same level that is relevant to clustering, but not related to EJB3's use of JBC.

To run the core part of the AS clustering testsuite:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh tests-clustering

That tests using the default UDP-based JGroups stacks. To run with both UDP and TCP (normally only necessary for final checks):

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh tests-clustering-all-stacks

ClusteredSingleSignOn is tested via a different target:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh tomcat-sso-clustered-tests

There is also a separate target for testing for classloader leaks due to clustering:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh tests-clustered-classloader-leak

As of 2008/10/23, on trunk there are intermittently one or two failures of the FieldGranularityClassLoaderLeakUnitTestCase, so don't regard that as a regression. All other tests pass, although there are infrequent intermittent failures in others.

The tests in the org.jboss.test.cluster.defaultcfg.simpleweb.test package mostly relate to JBC and can be run from inside an IDE.  The others need to be run from the command line.

To generate test reports and view in Firefox:

[bes@besdev ~]$ cd /home/bes/dev/JBC3_in_AS5/AS/Branch_JBoss_Cache_3/testsuite
[bes@besdev AS]$ ./build.sh tests-report-html
[bes@besdev AS]$ firefox output/reports/html/index.html

The EJB3 clustering testsuite is executed via Ant. Before executing, you need to set an environment variable telling the testsuite where to find your install of JBoss AS:

[bes@besdev testsuite]$ export JBOSS_HOME=/home/bes/dev/Branch_JBoss_Cache_3/AS/Branch_JBoss_Cache_3/build/output/jboss-5.0.0.GA/
[bes@besdev testsuite]$ ant -f build-test.xml clustered-tests

As of 2008/10/23, the NestedBeanUnitTestCase.testStatefulPassivation test intermittently fails.  The test is executed twice, once with buddy replication, once without, so you may see two failures. Any failure in a different test class or method or from a different assertion than the following should be regarded as a regression:

Remote nested passivate count:  expected:<3> but was:<8>
junit.framework.AssertionFailedError: Remote nested passivate count:  expected:<3> but was:<8>
     at org.jboss.ejb3.test.stateful.unit.NestedBeanTestRunner.testStatefulPassivation(NestedBeanTestRunner.java:182)
     at org.jboss.ejb3.test.clusteredsession.unit.NestedBeanUnitTestCase.testStatefulPassivation(NestedBeanUnitTestCase.java:113)
     at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)
     at junit.extensions.TestSetup$1.protect(TestSetup.java:23)
     at junit.extensions.TestSetup.run(TestSetup.java:27)

Building the EJB3 testsuite reports is also via Ant, although the report output is in the standard Maven location:

[bes@besdev testsuite]$ ant -f build-test.xml tests-report-html
[bes@besdev testsuite]$ firefox target/reports/html/index.html

Changing JBoss Cache / Pojo Cache Versions

As new CR2s, betas etc of JBoss Cache are PojoCache are published, you tell the AS to use them by editing the pom.xml file in the AS's component-matrix module.

    <version.org.jboss.cache.core>3.0.0.CR2</version.org.jboss.cache.core>
    <version.org.jboss.cache.pojo>3.0.0-SNAPSHOT</version.org.jboss.cache.pojo>

Initial Results

I ran the AS tests and the EJB3 tests and found the following:

1) The AS tests involving JBC and outside the org.jboss.test.cluster.defaultcfg.simpleweb.test package look good.

2) The EJB3 entity caching tests (in the org.jboss.ejb3.test.clusteredentity package) look good.

3) The tests in the org.jboss.test.cluster.defaultcfg.simpleweb.test package as well as the FIELD granularity (i.e. PojoCache) tests fail. Cause in all cases is likely this:

java.lang.NoSuchMethodError: org.jboss.cache.DefaultCacheFactory.getInstance()Lorg/jboss/cache/DefaultCacheFactory;
     at org.jboss.cache.pojo.impl.PojoCacheImpl.<init>(PojoCacheImpl.java:58)
     at org.jboss.cache.pojo.PojoCacheFactory.createCache(PojoCacheFactory.java:42)
     at org.jboss.test.cluster.testutil.SessionTestUtil.getConfiguration(SessionTestUtil.java:146)
     at org.jboss.test.cluster.testutil.SessionTestUtil.createCache(SessionTestUtil.java:135)
     at org.jboss.test.cluster.testutil.CacheConfigTestSetup.setUp(CacheConfigTestSetup.java:84)
     at junit.extensions.TestSetup$1.protect(TestSetup.java:18)
     at junit.extensions.TestSetup.run(TestSetup.java:23)

I think this is just a matter of Jason recompiling PojoCache against JBC core 3.0.0.CR2 (which has changed the return type of the above method to "CacheFactory") and then uploading a new snapshot.

4) The EJB3 SFSB clustering tests fail. A quick look at failure reports show this:

Caused by: java.lang.NullPointerException
     at org.jboss.cache.RegionImpl.registerEvictionEvent(RegionImpl.java:232)
     at org.jboss.cache.RegionImpl.unmarkNodeCurrentlyInUse(RegionImpl.java:166)
     at org.jboss.ejb3.cache.tree.StatefulTreeCache.release(StatefulTreeCache.java:262)
     at org.jboss.ejb3.cache.tree.StatefulTreeCache.release(StatefulTreeCache.java:69)
     at org.jboss.ejb3.stateful.StatefulContainer.createSession(StatefulContainer.java:491)
     at org.jboss.ejb3.session.SessionContainer.createSession(SessionContainer.java:550)
     at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.getNewSessionId(StatefulSessionProxyFactoryBase.java:296)
     at org.jboss.ejb3.proxy.factory.session.stateful.StatefulSessionProxyFactoryBase.createProxyBusiness(StatefulSessionProxyFactoryBase.java:160)
     at org.jboss.ejb3.proxy.objectfactory.session.SessionProxyObjectFactory.createProxy(SessionProxyObjectFactory.java:133)
     at org.jboss.ejb3.proxy.clustered.objectfactory.session.stateful.StatefulSessionClusteredProxyObjectFactory.getProxy(StatefulSessionClusteredProxyObjectFactory.java:66)
     at org.jboss.ejb3.proxy.objectfactory.ProxyObjectFactory.getObjectInstance(ProxyObjectFactory.java:153)
     at javax.naming.spi.NamingManager.getObjectInstance(NamingManager.java:304)
     at org.jnp.interfaces.NamingContext.getObjectInstance(NamingContext.java:1426)
     at org.jnp.interfaces.NamingContext.getObjectInstanceWrapFailure(NamingContext.java:1443)

The RegionImpl.evictionAlgorithm field is null.  StatefulTreeCache programatically creates eviction regions; likely the JBC 3 changes to the way eviction is handled are breaking with this usage.