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 <jason.greene@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@lists.jboss.org <mailto:jbosscache-dev@lists.jboss.org>
   https://lists.jboss.org/mailman/listinfo/jbosscache-dev

--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry@redhat.com