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
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
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
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
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
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
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
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
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
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
10 matches
Mail list logo
