Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core

2008-10-18 Thread Manik Surtani 
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]>

> 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
> [EMAIL PROTECTED]
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core

2008-10-18 Thread Brian Stansberry 
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  CacheFactory 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] 
>


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

Re: [jbosscache-dev] Re: [hibernate-dev] cache-jbosscache3 module for Hibernate Core

2008-10-18 Thread Brian Stansberry 
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  CacheFactory 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] 
>


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