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.

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 >

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

Brian Stansberry wrote: > Steve Ebersole wrote: > >> so JBC 3 needs this change anyway? >> > > Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite sure the > JBC team wants, since they made a bunch of other more significant changes to > ensure compatibility. This one's real trivial. > > at which point it would be a total >> drop-in replacement? >> >> > Yes. I just did a diff between head of trunk (which passes 100% w/ JBC > 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA tag and the only > differences are two places where the missing > DefaultCacheFactory.getInstance() call was replaced. > I fixed this compatibility problem awhile ago, but it could have been after CR1 was tagged. -- Jason T. Greene JBoss, a division of Red Hat _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev

Sorry, Manik, tests were failing w/ NoSuchMethodError and I saw your recent change in hibernate trunk to remove use of DefaultCacheFactory.getInstance() and assumed the method was gone. My bad :-( Perhaps problem is loss of generics info in the class file? 2.1.0.GA: public static <K, V> CacheFactory<K, V> getInstance() 3.0.0.CR1: public static DefaultCacheFactory getInstance() Failure I see is: java.lang.NoSuchMethodError: org.jboss.cache.DefaultCacheFactory.getInstance()Lorg/jboss/cache/CacheFactory; at org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.createSharedCache(SharedCacheInstanceManager.java:193) I don't remember exactly how I tested this yesterday, but messing with it today, I can reproduce by: 1) revert pom in my checkout of the 3.3.1 tag so it uses JBC 2.1.0.GA 2) revert any compiled classes back to the original 3.3.1 mvn -Dmaven.test.skip.exec=true clean install 3) change the pom so it uses JBC 3.3.0.CR1 and JGroups 2.6.5 4) run the testsuite mvn -Ptest test .... Tests run: 225, Failures: 0, Errors: 21, Skipped: 0 5) force a new compile and then retest: mvn -Ptest clean test ... Tests run: 225, Failures: 0, Errors: 0, Skipped: 0 Problem is people using a 3.3.1 binary don't get to recompile. ;) Manik Surtani wrote: > Weird, getInstance() was removed in early ALPHAs, and was replaced > again pretty quickly - in 3.0.0.BETA1, even. > > http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main... > > > > > 2008/10/18 Jason T. Greene <jason.greene(a)redhat.com > <mailto:jason.greene@redhat.com>> > > Brian Stansberry wrote: > > Steve Ebersole wrote: > > so JBC 3 needs this change anyway? > > Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite > sure the JBC team wants, since they made a bunch of other more > significant changes to ensure compatibility. This one's real > trivial. > > at which point it would be a total > drop-in replacement? > > > Yes. I just did a diff between head of trunk (which passes 100% > w/ JBC 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA > <http://hibernate-3.3.1.GA> tag and the only differences are two > places where the missing DefaultCacheFactory.getInstance() call > was replaced. > > > I fixed this compatibility problem awhile ago, but it could have > been after CR1 was tagged. > > -- Jason T. Greene > > JBoss, a division of Red Hat > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > <mailto:jbosscache-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/jbosscache-dev > >

lol! thanks, will fix this in trunk now and publish a snapshot of 3.0.0. 2008/10/18 Brian Stansberry <brian.stansberry(a)redhat.com&gt; Elias Ross was kind enough to notify me privately that the difference in > method signature isn't the generics (which of course don't matter at > runtime), it's the change in return type from CacheFactory to > DefaultCacheFactory. DOH! > > Maxim: if the only remaining answer is impossible, don't decide the > impossible is the answer. Look again and see the blindingly obvious > possible answer. :-) > > > Brian Stansberry wrote: > >> Sorry, Manik, tests were failing w/ NoSuchMethodError and I saw your >> recent change in hibernate trunk to remove use of >> DefaultCacheFactory.getInstance() and assumed the method was gone. My bad >> :-( >> >> Perhaps problem is loss of generics info in the class file? >> >> 2.1.0.GA: >> >> public static <K, V> CacheFactory<K, V> getInstance() >> >> 3.0.0.CR1: >> >> public static DefaultCacheFactory getInstance() >> >> Failure I see is: >> >> java.lang.NoSuchMethodError: >> org.jboss.cache.DefaultCacheFactory.getInstance()Lorg/jboss/cache/CacheFactory; >> >> at >> org.hibernate.cache.jbc2.builder.SharedCacheInstanceManager.createSharedCache(SharedCacheInstanceManager.java:193) >> >> >> >> I don't remember exactly how I tested this yesterday, but messing with it >> today, I can reproduce by: >> >> 1) revert pom in my checkout of the 3.3.1 tag so it uses JBC 2.1.0.GA >> 2) revert any compiled classes back to the original 3.3.1 >> mvn -Dmaven.test.skip.exec=true clean install >> >> 3) change the pom so it uses JBC 3.3.0.CR1 and JGroups 2.6.5 >> 4) run the testsuite >> >> mvn -Ptest test >> .... >> Tests run: 225, Failures: 0, Errors: 21, Skipped: 0 >> >> 5) force a new compile and then retest: >> >> mvn -Ptest clean test >> ... >> Tests run: 225, Failures: 0, Errors: 0, Skipped: 0 >> >> >> Problem is people using a 3.3.1 binary don't get to recompile. ;) >> >> Manik Surtani wrote: >> >>> Weird, getInstance() was removed in early ALPHAs, and was replaced again >>> pretty quickly - in 3.0.0.BETA1, even. >>> >>> >>> http://fisheye.jboss.org/browse/JBossCache/core/tags/3.0.0.BETA1/src/main... >>> >>> >>> >>> 2008/10/18 Jason T. Greene <jason.greene(a)redhat.com <mailto: >>> jason.greene(a)redhat.com&gt;&gt; >>> >>> Brian Stansberry wrote: >>> >>> Steve Ebersole wrote: >>> >>> so JBC 3 needs this change anyway? >>> Yes, if it wants to go in, say, JBoss AS 5.2. Which I'm quite >>> sure the JBC team wants, since they made a bunch of other more >>> significant changes to ensure compatibility. This one's real >>> trivial. >>> >>> at which point it would be a total >>> drop-in replacement? >>> >>> >>> Yes. I just did a diff between head of trunk (which passes 100% >>> w/ JBC 3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA >>> <http://hibernate-3.3.1.GA> tag and the only differences are two >>> places where the missing DefaultCacheFactory.getInstance() call >>> was replaced. >>> >>> >>> I fixed this compatibility problem awhile ago, but it could have >>> been after CR1 was tagged. >>> >>> -- Jason T. Greene >>> >>> JBoss, a division of Red Hat >>> _______________________________________________ >>> jbosscache-dev mailing list >>> jbosscache-dev(a)lists.jboss.org <mailto: >>> jbosscache-dev(a)lists.jboss.org&gt; >>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>> >>> >>> >> >> > > -- > Brian Stansberry > Lead, AS Clustering > JBoss, a division of Red Hat > brian.stansberry(a)redhat.com >