On 15/05/2015 16:38, Scott Marlow wrote: > Applications that compile against Infinispan 6.x, will expect that > org.infinispan.configuration.cache.EvictionConfiguration.maxEntries() > returns an int but when they run against Infinispan 7.x, they will not > find this method (since maxEntries() returns a long). > > Is this a known bug or issue on Infinispan 7.x? Since this was changed in a minor release (7.2) it definitely is a bug. While we can provide overloaded setters, doing so for a getter is obviously not possible. We should probably release a 7.2.2 which restores "int maxEntries()" and adds a "long maxEntriesAsLong()".

However be aware that for 8.0 we want to remove the "int" variants altogether.

Yes the hibernate-infinispan module will need maintenance as usual, but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10 has to have Hibernate 5.

We can focus on the hibernate-infinispan module in branch master only (Hibernate 5), but also let's try to not realize update needs last minute.

On 15 May 2015 at 18:16, Scott Marlow <smarlow(a)redhat.com&gt; wrote: > > > On 05/15/2015 12:43 PM, Sanne Grinovero wrote: >> Yes the hibernate-infinispan module will need maintenance as usual, >> but don't bother to update Infinispan in Hibernate 4.3, as WildFly 10 >> has to have Hibernate 5. > > This is a valid choice but also means that Infinispan 8 will not work > with WildFly 10, if Hibernate 5 is not ready in time for the WildFly 10 > release. I think that we all probably heard that WildFly 10 is supposed > to be a short release. Perhaps the involved project leads should > discuss this (Infinispan/HibernateOrm/WildFly) and sync up on scheduling > so there are no surprises/last minute integration efforts. Infinispan doesn't depend on a specific version of Hibernate, so while I'm pretty sure that Infinispan 8 will be ready on time I don't see why that would be a problem if - hypothetically - at last minute WildFly 10 were to pick Infinispan 7 instead. >> We can focus on the hibernate-infinispan module in branch master only >> (Hibernate 5), but also let's try to not realize update needs last >> minute. > > To me this is more of a personal preference on how the one person that > knows how to do the integration (between Infinispan/Hibernate), does > their work. But, sure, lets "try". Perhaps keeping a > hibernate-infinispan branch up to date Infinispan changes, would be > helpful. Galder, I hope these suggestions are helpful and not as > annoying as I suspect they may be. ;) It might not be a good idea to update Hibernate to a version of Infinispan which might not be included, until you're sure. I agree it's nice to try keeping up - in secondary branches - to make sure one is aware of what might be needed, and possibly raise issues in advance. And anyone can start such an experiment. For sure Galder is the most expert on the module, but with "let's try" I really meant all of us. This has to be cross-team teamwork. It's not an unilateral decision of the Hibernate team to pick which version is being merged in WildFly, and so for Infinispan. WildFly being the integration, it's up to WildFly to choose a compatible combination, and that's not necessarily the latest of each. So while project leads and components leads can give some advice, ultimately it's up to who needs them to work together who should watch out, possibly running integration tests and TCKs well in advance to see integration issues coming. The earlier reported, the better for all. Also note that one project *might not want to* depend on the version which WildFly plans to use.. really WildFly should be prepared to run his own tests overriding the versions, and I wouldn't advice starting such a job during CR1.

Thanks, Sanne _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev