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

[Manik Surtani]

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 <manik at jboss.org>

> lol!  thanks, will fix this in trunk now and publish a snapshot of 3.0.0.
>
> 2008/10/18 Brian Stansberry <brian.stansberry at redhat.com>
>
> 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 at redhat.com <mailto:
>>>> jason.greene at 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 at lists.jboss.org <mailto:
>>>> jbosscache-dev at lists.jboss.org>
>>>>    https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Brian Stansberry
>> Lead, AS Clustering
>> JBoss, a division of Red Hat
>> brian.stansberry at redhat.com
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/hibernate-dev/attachments/20081019/5619e805/attachment.html