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 Sur
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 i
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
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 CacheFacto
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
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
d
so JBC 3 needs this change anyway? at which point it would be a total
drop-in replacement?
Just want to make sure i fully understand.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROTECTED]
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.co
Just ran the current trunk testsuite for cache-jbosscache2 using JBC
3.0.0.CR1 and there are no problems.
However, there are a 21 failures trying to use 3.0.0.CR1 in Hibernate
3.3.1. All seem to be due to the removal of the
DefaultCacheFactory.getInstance() method. The failing calls are not i
I think we should officially move to "inclusion" of JBossCache 3.0 in
3.4 which is not too far off. For 3.3 it is easy enough for users to
override Hibernate's declaration of JBossCache version to use 3.0 via
Maven *provided* the API really is compatible (drop-in replacement
wise)
-
Steve Ebe
Too bad y'all did not isolate the API then :(
It may be confusing to users, but I think we need to stay with
hibernate-jbosscache2. Worst case we can push that this is our "second
attempt" at integration as the reason for the '2'.
-
Steve Ebersole
Project Lead
http://hibernate.org
[EMAIL PROT
On 13 Oct 2008, at 15:18, Brian Stansberry wrote:
Manik Surtani wrote:
Guys,
The API of JBC 3.0 is compatible with 2.x so the actual provider
code should not change, but we probably want to test MVCC as a
locking scheme as well.
So, we either
1) need a cache-jbosscache3 module (yuk!), co
Manik Surtani wrote:
Guys,
The API of JBC 3.0 is compatible with 2.x so the actual provider code
should not change, but we probably want to test MVCC as a locking scheme
as well.
So, we either
1) need a cache-jbosscache3 module (yuk!), copy the providers and
existing tests from cache-jbos
12 matches
Mail list logo
