JBCLUSTER-206 - Extract HB/JBC integration layer from EJB3

[galder.zamarreno]

re: https://jira.jboss.org/jira/browse/JBCLUSTER-206

I've decided to have a go at this. Brian kindly provided with a set of steps of what he thinks needs doing:

1) Decide on a name for binary and module in svn. I think for now it will live in repos/jbossas/projects/cluster. Only sucky thing is version #s in JIRA, since it doesn't really follow the ha-client and ha-server-api. But we can deal w/ that later; for now let's just get something to Prabhat.

2) Setup maven project. Should be fairly straightforward.

3) Copy classes from Branch_4_2/ejb3/src/main/org/jboss/ejb3/entity

4) Rename, repackage classes (no ejb3)

5) The actual code change, which I *think* is pretty straightforward. Won't get into that here.

1-5 has been done. I now have a separate project with 2nd level cache integration layer created for ejb3 entities separated and not dependant on ejb3.

6) Give a binary to Prabhat, let him play. Sort out integration issues (e.g. they have their own CacheProvider impl that finds the cache in JMX; need to coordinate with that.)

7) Testing. This is the painful part. I'm thinking maybe it's possible to just pull the tests from the ejb3 testsuite, and then make it a requirement that user sets a $JBOSS_HOME, and then we use that to figure out how to start a couple JBoss instances to run the tests. Not sure if the server launch stuff in the testsuite supports such a thing. Probably you know better after your adventures last week. Perhaps some tests could be pulled out of the Hibernate 3.3/JBC 2 integration as well.

6 and 7 are left to do. I'd like to focus on 7 for the time being:

On 7, Brian suggested pulling ejb3 tests and running them within two JBoss AS instances. I'm not sure whether Brian refers to unit tests for the module I've created (temporily called hibernate-cache-jbc) or you're refering to tests within portal. Personally, I'd like to have some unit tests in the standalone module and I'd like to avoid AS dependency. Could you start within a UT two instances of HB + corresponding JBC cache and share a database between them? I haven't looked at this yet (it's Friday eve and I'm about to go for a few drinks :p, no time for more digging troday), I'm just putting out there to see whether anyone's done this before (I suppose HB33/JBC2 has examples of this, need to investigate). If we managed to achieve this, we could easily port the EJB3 clustered entity tests and convert them to using HB Session instead of JPA entity manager.I agree with adding some HB33/JBC2 unit tests as well.

Bottom line: I'd be a much happier person if I can avoid AS for tests for the hibernate-cache-jbc module.

[brian.stansberry]

Re: the tests, there are tests in the Hibernate 3.3 core cache-jboss-cache2 module that avoid using the AS. See the org.hibernate.test.cache.jbc2.functional package. The difficulty is those bring in dependencies on the Hibernate test module, plus I'm sure have JBC 2 ties. So it will require some effort to break those ties and let them run standalone.

There are lots of other tests in Hibernate 3.3 core cache-jboss-cache2 as well; none require the AS. But those are much more tied to the Hibernate 3.3 and JBC 2 APIs.

On the name, how about "hibernate-jbc-cache-provider"? CacheProvider is the legacy API that's replaced in 3.3. Including it in the name is at least a small indication this is a legacy integration.

[galder.zamarreno]

Re: the tests, there are tests in the Hibernate 3.3 core cache-jboss-cache2 module that avoid using the AS. See the org.hibernate.test.cache.jbc2.functional package. The difficulty is those bring in dependencies on the Hibernate test module, plus I'm sure have JBC 2 ties. So it will require some effort to break those ties and let them run standalone.

I've started looking at the dependencies on the test module. Hibernate 3.2.x never produced any binaries with the test classes required to port the org.hibernate.test.cache.jbc2.functional tests. Since 3.3.x though, such jar has been made available (http://repository.jboss.org/maven2/org/hibernate/hibernate-testing/3.3.0.CR1/). I've done a diff between the test classes in 3.2.x and trunk and they're almost identical with a few minor differences such as: use of org.slf4j rather than commons logging, and refactoring of DummyConnectionProvider and DummyTransactionManagerLookup into ConnectionProviderImpl and TransactionManagerLookupImpl. There's also a 2 of extra methods in UnitTestCase (createFailureExpectedSuite() method), FunctionalTestCase (isSerializableIsolationEnforced() method) and removed FunctionalTestClassTestSuite(String) constructor from FunctionalTestClassTestSuite.

Bottom line: I think I can safely add a dependency for HB 3.3 hibernate testing even though we're testing HB 3.2.x. WDYT? This would much easier than having to now come up with testing jars for 3.2.x series. The downside here is that if we pull 3.3 hibernate testing module, we're indirectly pull other jars but I don't see any direct incompatibilities with what we pull right now for 3.2.x:

M2_REPO/junit/junit/3.8.1/junit-3.8.1.jar
M2_REPO/antlr/antlr/2.7.6/antlr-2.7.6.jar
M2_REPO/commons-collections/commons-collections/3.1/commons-collections-3.1.jar
M2_REPO/dom4j/dom4j/1.6.1/dom4j-1.6.1.jar
M2_REPO/xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2.jar
M2_REPO/javax/transaction/jta/1.1/jta-1.1.jar
M2_REPO/org/slf4j/slf4j-api/1.4.2/slf4j-api-1.4.2.jar

I think it'd be interesting to get Steve's thoughts on this. Thoughts?

On the name, how about "hibernate-jbc-cache-provider"? CacheProvider is the legacy API that's replaced in 3.3. Including it in the name is at least a small indication this is a legacy integration.

I like the name, just one little thing. To make the legacy aspect even more obvious, I'd suggest making cache-provider a single word, matching the class CacheProvider class name: i.e. hibernate-jbc-cacheprovider. As an extension of this, I suppose the package name for this classes would be something along: org.jboss.hibernate.jbc.cacheprovider

[galder.zamarreno]

A question with regards to org.hibernate.test.cache in hibernate-testing module and org.hibernate.test.cache.jbc2.functional package in cache-jbosscache2:

cache-jbosscache2 uses hibernate-testing but for some reason, it seems to redefine Item, VersionedItem and Item.hbm.xml. However, after comparing them, they look identical. This is important for me in case I can just use these classes from hibernate-testing module, or you're planning to remove these from here and keep the ones in cache-jbosscache2, in which case I'd need to redefine them for hibernate-jbc-cacheprovider.

[brian.stansberry]

Re: using the 3.3 version of hibernate-testing, I think it's a valid workaround to make progress. If we don't like it later we can always port the needed classes in hibernate-jbc-cacheprovider.

+1 on getting Steve's opinion.

Re: the name, hibernate-jbc-cacheprovider and the package name sound good.

Re: the Item class et al, I suspect when I first created them they were not in hibernate-testing but rather the hibernate testsuite module, on which cache-jbosscache2 couldn't depend (it would have been circular). Steve probably later moved them to hibernate-testing. I know he moved other stuff I needed. If the hibernate-testing ones work, that's fine.

[galder.zamarreno]

Indeed. For the time being I've added a dependency on hibernate-testing 3.3.0.CR1 which lets me move forward and tackle the more difficult part of the UT testing, which is making your tests work with JBC 1.x.

I've forwarded the thread to Steve but it might take a while for him to come back as he's in Tuscany with the rest of Seam/Hibernate guys.

Right, I understand now how that duplication come about. I'll stick to hibernate-testing for the time being.

[galder.zamarreno]

Re: pulling hibernate-testing 3.3. I've just realised that it pulls hibernate core 3.3, so you end up with Hibernate 3.2 and 3.3 in the classpath. I'm reverting back to pulling the classes the test classes that I need from 3.2 into hibernate-jbc-cacheprovider

[brian.stansberry]

Don't get too hung up on this testing integration. This is why #6 (work w/ Prabhat) came before #7 on my list. We can come up with hacky ways to manually run the EJB3 entity clustering testsuite with the new code. If it passes I want to get a binary to Prabhat ASAP so we can see if it actually helps him.

You said you have 1-5. Please commit it so I can see it. :-)

[galder.zamarreno]

I've got 1-5 plus .functional package tests running. It still needs some polishing because the set up and tear down execution phases of these tests is a <insert_a_lovely_word_here> mess, so if I run several tests together, they fail. Why? Well, because there's part of the set up code that is only run once per test case execution and other part that is run before each individual test. This is making it hard for me to figure out where on earth I need to put tear down code.

On top of that, things vary between single node and multi node tests, i.e. for multi node tests, one of the node's cache is set up once per unit test case class, whereas for the other is set up before each single test method.

Anyway, as Brian said, I think I have enough now to build a binary, so I'm gonna leave the testing to a side and focus on creating the binary and integrating it with Portal 2.7.x.

I'll commit the code today or tomorrow.

[galder.zamarreno]

Btw, apologies for the late reply but for some reason I didn't get an email for Brian's reply.

[galder.zamarreno]

https://svn.jboss.org/repos/jbossas/projects/cluster/hibernate-jbc-cacheprovider/trunk/

[galder.zamarreno]

http://anonsvn.jboss.org/repos/jbossas/projects/cluster/hibernate-jbc-cacheprovider/trunk/

[galder.zamarreno]

I'm now gonna try to build a jar and integrate it with Portal 2.7.x.

[brian.stansberry]

Cool. I'll have a look later today.

[galder.zamarreno]

I'm back :)

Local puts only enhancement is now coded, tested and committed. Switched the tests to READ_COMMITTED.
Removed *Hook from the cache provider names.

I'll now work on the integration part so that Prabhat can start testing asap.