so JBC 3 needs this change anyway? at which point it would be a total drop-in replacement?
Just want to make sure i fully understand. - Steve Ebersole Project Lead http://hibernate.org [EMAIL PROTECTED] Principal Software Engineer JBoss, a division of Red Hat http://jboss.com http://redhat.com [EMAIL PROTECTED] [EMAIL PROTECTED] On Fri, 2008-10-17 at 16:48 -0500, Brian Stansberry wrote: > 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 > > [EMAIL PROTECTED] > > > > Principal Software Engineer > > JBoss, a division of Red Hat > > http://jboss.com > > http://redhat.com > > [EMAIL PROTECTED] > > [EMAIL PROTECTED] > > > > > > 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 > >>> [EMAIL PROTECTED] > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev