Re: [hibernate-dev] NoSuchMethodError running hibernate-infinispan tests with Infinispan 7.2.1

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