7:41 a.m.
Following Steve's suggestion using resolutionStrategy, I was able to build the
hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with
7.2.1.Final.
I'm sure there's a more elegant way to do this, so I've created a new jira
(HHH-9802) and a pull request with the change I made:
https://github.com/hibernate/hibernate-orm/pull/955 .
There were actually some unit test failures in InfinispanRegionFactoryTestCase using
7.2.1.Final due to java.lang.NoSuchMethodError.
It happens in assertions like:
assertEquals(5000, cacheCfg.eviction().maxEntries());
The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in
the unit tests. I can probably workaround this in the unit test, but I was wondering if
this could cause a problem if an application used this method directly.
Galder, do you know if this is a concern?
I have instructions in the pull request for reproducing these failures.
I commented out the failing assertions locally to verify that nothing else causes the test
to fail.
I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as
an int. That gets initialized based on a value set for on
hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see
TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does
this actually get used anywhere? Does the value find its way into a
EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in
master?
I had a quick chat with Scott Marlow when I realized this was a potential problem and we
agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead
and released 4.3.10.Final.
I will check in on things Friday morning, but I have to leave by 10:30am and will be off
the rest of the day. I can pick this up on Monday if need be.
Regards,
Gail
4:32 p.m.
On 05/15/2015 01:41 AM, Gail Badner wrote:
Following Steve's suggestion using resolutionStrategy, I was able
to build the hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests
with 7.2.1.Final.
I'm sure there's a more elegant way to do this, so I've created a new jira
(HHH-9802) and a pull request with the change I made:
https://github.com/hibernate/hibernate-orm/pull/955 .
There were actually some unit test failures in InfinispanRegionFactoryTestCase using
7.2.1.Final due to java.lang.NoSuchMethodError.
It happens in assertions like:
assertEquals(5000, cacheCfg.eviction().maxEntries());
The problem is that org.infinispan.configuration.cache.EvictionConfiguration.maxEntries()
returns int in 6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in
the unit tests. I can probably workaround this in the unit test, but I was wondering if
this could cause a problem if an application used this method directly.
Galder, do you know if this is a concern?
I have instructions in the pull request for reproducing these failures.
I commented out the failing assertions locally to verify that nothing else causes the
test to fail.
I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined as
an int. That gets initialized based on a value set for on
hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see
TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does
this actually get used anywhere? Does the value find its way into a
EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in
master?
I had a quick chat with Scott Marlow when I realized this was a potential problem and we
agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone ahead
and released 4.3.10.Final.
As far as I can tell, applications that compile against Infinispan 6.x,
will be expecting cacheCfg.eviction().maxEntries() to always be an int
(as Gail states). Those applications will be broken when they try to
drop in Infinispan 7.x. I don't think this is a Hibernate bug but think
we need input from infinispan-dev. I'll try cross posting on that
mailing list.
I will check in on things Friday morning, but I have to leave by 10:30am and will be off
the rest of the day. I can pick this up on Monday if need be.
Regards,
Gail
9:22 a.m.
This is not problematic for 2LC users because except in testing, we never check this value
in the production code. IOW, in production we set max entries but we don't query it,
so it's not problematic. In testing, we verify that the cache's eviction max
entries is the one we've configured via the Hibernate/JPA configuration, but
that's it.
Thanks Gail for all the hard work!! :)
On 15 May 2015, at 16:32, Scott Marlow <smarlow(a)redhat.com>
wrote:
On 05/15/2015 01:41 AM, Gail Badner wrote:
> Following Steve's suggestion using resolutionStrategy, I was able to build the
hibernate-infinispan jar with Infinispan 6.0.0.Final and run the unit tests with
7.2.1.Final.
>
> I'm sure there's a more elegant way to do this, so I've created a new
jira (HHH-9802) and a pull request with the change I made:
https://github.com/hibernate/hibernate-orm/pull/955 .
>
> There were actually some unit test failures in InfinispanRegionFactoryTestCase using
7.2.1.Final due to java.lang.NoSuchMethodError.
>
> It happens in assertions like:
>
> assertEquals(5000, cacheCfg.eviction().maxEntries());
>
> The problem is that
org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() returns int in
6.0.0.Final, but returns long in 7.2.1.Final. The only usage I see is in the unit tests. I
can probably workaround this in the unit test, but I was wondering if this could cause a
problem if an application used this method directly.
>
> Galder, do you know if this is a concern?
>
> I have instructions in the pull request for reproducing these failures.
>
> I commented out the failing assertions locally to verify that nothing else causes the
test to fail.
>
> I also see org.hibernate.cache.infinispan.TypeOverrides.evictionMaxEntries is defined
as an int. That gets initialized based on a value set for on
hibernate.cache.infinispan.<classnam>.eviction.max_entries. The only place I see
TypeOverrides.getEvictionMaxEntries() used is in InfinispanRegionFactoryTestCase. Does
this actually get used anywhere? Does the value find its way into a
EvictionConfiguration.maxEntries field? If so, should be a long (instead of an int) in
master?
>
> I had a quick chat with Scott Marlow when I realized this was a potential problem and
we agreed that it shouldn't block releasing Hibernate ORM 4.3.10.Final. I have gone
ahead and released 4.3.10.Final.
As far as I can tell, applications that compile against Infinispan 6.x, will be expecting
cacheCfg.eviction().maxEntries() to always be an int (as Gail states). Those applications
will be broken when they try to drop in Infinispan 7.x. I don't think this is a
Hibernate bug but think we need input from infinispan-dev. I'll try cross posting on
that mailing list.
>
> I will check in on things Friday morning, but I have to leave by 10:30am and will be
off the rest of the day. I can pick this up on Monday if need be.
>
> Regards,
> Gail
>
--
Galder Zamarreño
galder(a)redhat.com
3265
days inactive
3269
days old
2 comments
3 participants
participants (3)
-
Gail Badner -
Galder Zamarreño -
Scott Marlow