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 >