I have already solved that using filterEntries [1], but that's not end of the pain. Another change is ISPN removing ExtendedModuleCommandsFactory - I could not get around that with Infinispan snapshot. And if Infinispan does not keep fixed API even between major versions, these attempts to sync it seem quite futile.
Radim [1] https://github.com/hibernate/hibernate-orm/pull/1045 On 08/06/2015 04:17 PM, William Burns wrote: > > > On Thu, Aug 6, 2015 at 4:42 AM Tristan Tarrant <[email protected] > <mailto:[email protected]>> wrote: > > > > On 06/08/2015 10:30, Sanne Grinovero wrote: > > On 6 August 2015 at 03:01, William Burns <[email protected] > <mailto:[email protected]>> wrote: > >> It seems ORM was compiled with a version earlier than Beta1 but > then ran > >> with Beta2? The keySet method was changed to return a subclass of > >> CloseableIteratorSet with Beta2 to support distributed streams [1]. > > > > BTW that CacheSet API change looks like it was intended to be > > backwards compatible? It's not, as we just realised. I you want > it to > > be backwards compatible you'll have to revert that API change. > > From the ORM version numbers (CR4) I guess we are near endgame and we > MUST ensure that ORM works with both Infinispan 7.x and 8.x. > Will is it possible to make the signature of the method backwards > compatible ? > > > The method is backwards compatible when compiling and running against > ISPN 8. > > I don't think there is any way here to make this backwards compatible > changing only ISPN with varying versions at runtime without adding new > methods in ISPN 8 which are identical to keySet, values and entrySet > except the return type for them are defined as returning the new > CacheSet/CacheCollection interfaces. The underlying implementation > for the duplicates would be identical however. Without those new > methods we wouldn't have access to the more advanced options when > using distributed streams unless we manually casted. This doesn't > sound too appealing to me. > > If this is inconvenient, what can be done in Hibernate Infinispan to > insulate it from this change ? > > > This code is essentially doing a clear, but can this code live with > the semantics of clear [1] that are the same between ISPN 7 & 8? I am > guessing not. > > We could add a utility method in ISPN 7 & 8 that is defined as > returning a ClosebaleIteratorSet/Collection that would be identical in > both versions that we could also do [2]. Then if ORM calls the > appropriate static method instead of keySet, values, entrySet it would > be backwards runtime compatible as well. > > > Still, I'm wondering whether hibernate-infinispan shouldn't be > subclassed into multiple versions so that we can be a bit more liberal > with some changes. > > > This does hamper changes quite a bit. This change was pretty minor, I > can't imagine if they are using some class/method that we are removing > in ISPN 8. > > > Tristan > > -- > Tristan Tarrant > Infinispan Lead > JBoss, a division of Red Hat > _______________________________________________ > infinispan-dev mailing list > [email protected] <mailto:[email protected]> > https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > [1] > https://github.com/infinispan/infinispan/blob/7.2.x/core/src/main/java/org/infinispan/Cache.java#L329 > > > [2] https://gist.github.com/wburns/c3d3d95483d35be4b8c6 > > > _______________________________________________ > infinispan-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Radim Vansa <[email protected]> JBoss Performance Team _______________________________________________ infinispan-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/infinispan-dev
