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
