[jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core

Just ran the current trunk testsuite for cache-jbosscache2 using JBC 3.0.0.CR1 and there are no problems. However, there are a 21 failures trying to use 3.0.0.CR1 in Hibernate 3.3.1. All seem to be due to the removal of the DefaultCacheFactory.getInstance() method. The failing calls are not in the testsuite; they are in the main code. So, JBC 3 as is will not work in Hibernate 3.3. To have JBC 3 be considered API compatible for inclusion in AS 5.x, this method would need to be restored. Steve Ebersole wrote: > I think we should officially move to "inclusion" of JBossCache 3.0 in > 3.4 which is not too far off. For 3.3 it is easy enough for users to > override Hibernate's declaration of JBossCache version to use 3.0 via > Maven *provided* the API really is compatible (drop-in replacement > wise) > > - > > Steve Ebersole > Project Lead > http://hibernate.org > steve(a)hibernate.org > > Principal Software Engineer > JBoss, a division of Red Hat > http://jboss.com > http://redhat.com > steve.ebersole(a)jboss.com > steve.ebersole(a)redhat.com > > > On Mon, 2008-10-13 at 09:18 -0500, Brian Stansberry wrote: >> Manik Surtani wrote: >>> Guys, >>> >>> The API of JBC 3.0 is compatible with 2.x so the actual provider code >>> should not change, but we probably want to test MVCC as a locking scheme >>> as well. >>> >>> So, we either >>> >>> 1) need a cache-jbosscache3 module (yuk!), copy the providers and >>> existing tests from cache-jbosscache2 and add a few extra tests. >>> >>> or, >>> >>> 2) assume that cache-jbosscache2 refers to an API and not a version of >>> the cache. So update the cache used in cache-jbosscache2 to 3.0.0, and >>> add the extra MVCC tests as well. >>> >>> My pref would be for 2, what do you guys think? >>> >> Had a *quick* look at the code, and looks like the only direct use of >> the JBC node locking scheme is a check for OPTIMISTIC in the JBC config, >> which if true leads to use of classes that store versions in the cache. >> With MVCC we don't need to store versions, so looks like the existing >> logic is fine. >> >> If the hibernate guys object to changing the dependency to 3.x, we could >> look at handling this via a maven profile. If there's no compile time >> dependency on JBC 3 in the main code or the tests (likely, since MVCC is >> configured via XML) then we could isolate execution of the MVCC tests in >> a profile. >> >> Downside to the profile approach is the standard JBC configs that ship >> would still use PESSIMISTIC/OPTIMISTIC. >> >>> Cheers >>> -- >>> Manik Surtani >>> Lead, JBoss Cache >>> manik(a)jboss.org >>> >>> >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev(a)lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >