By the way, there's some feedback on using 3.0.0 as a 2nd level cache on Hibernate here (see comments at the end):
http://jbosscache.blogspot.com/2008/09/first-cr-for-300.html "I notice MVCC uses significantly less memory for my use case compared to both 2.2 and Coherence." 2008/10/19 Manik Surtani <[EMAIL PROTECTED]> > lol! thanks, will fix this in trunk now and publish a snapshot of 3.0.0. > > 2008/10/18 Brian Stansberry <[EMAIL PROTECTED]> > > 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/java/org/jboss/cache/DefaultCacheFactory.java?r=6676 >>>> >>>> >>>> >>>> 2008/10/18 Jason T. Greene <[EMAIL PROTECTED] <mailto: >>>> [EMAIL PROTECTED]>> >>>> >>>> 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 >>>> [EMAIL PROTECTED] <mailto: >>>> [EMAIL PROTECTED]> >>>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev >>>> >>>> >>>> >>> >>> >> >> -- >> Brian Stansberry >> Lead, AS Clustering >> JBoss, a division of Red Hat >> [EMAIL PROTECTED] >> > >
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
