-
Bug
-
Resolution: Done
-
Major
-
7.0.0.Beta1
-
None
-
None
The idea here is to try to produce a Infinispan 7.0 jar that's binary compatible with 6.0 in order to ease upgrading. So far, the following elements have been found to be problematic:
- FileLookupFactory -> FileLookup changes -
ISPN-3850 - JBossStandaloneJTAManagerLookup.init changes -
ISPN-3850 - org.infinispan.AbstractDelegatingAdvancedCache refactoring to org.infinispan.cache.impl.AbstractDelegatingAdvancedCache -
ISPN-4074
XML configuration stays apart since one of the key aspects of 7.0 is to produce WF-like configuration that's as close as possible, to improve usability between library and server mode.
- is related to
-
ISPN-3850 Introduce non-static utility to handle classloading hierarchy
-
- Closed
-
-
ISPN-4074 Only include public API in JavaDoc
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
[ISPN-4686] Make Infinispan 7.0 binary compatible with 6.x
Galder Zamarreño
added a comment - Tristan, I think it doesn't hurt to have a path for people upgrading, even in major versions. Paul is very much a user, like a lot out there, but doing more advanced stuff with Infinispan. I think his concerns are valid.
Galder Zamarreño
added a comment - Tristan, I think it doesn't hurt to have a path for people upgrading, even in major versions. Paul is very much a user, like a lot out there, but doing more advanced stuff with Infinispan. I think his concerns are valid. NadirX the abstract delegating cache/cache manager classes were actually meant for end users to subclass so that they wouldn't break when we added a new method (ISPN-1526).
We also expect the user to select a consistent hash factory by specifying the full class name, so I would consider those class names part of the public API.
Tristan Tarrant
added a comment - pferraro@redhat.com the classes you list as "incompatibilies" (aside possibly from Dialect/DatabaseType) are really not supposed to be public API and they have been moved for cleanliness.
Tristan Tarrant
added a comment - pferraro@redhat.com the classes you list as "incompatibilies" (aside possibly from Dialect/DatabaseType) are really not supposed to be public API and they have been moved for cleanliness. Other incompatibilities:
- org.infinispan.manager.AbstractDelegatingEmbeddedCacheManager
> org.infinispan.manager.impl.AbstractDelegatingEmbeddedCacheManager <ISPN-4074 - org.infinispan.cache.impl.AbstractDelegatingCache
> org.infinispan.AbstractDelegatingCache <ISPN-4074 - org.infinispan.affinity.KeyAffinityServiceImpl
> org.infinispan.affinity.impl.KeyAffinityServiceImpl <ISPN-4074 - org.infinispan.persistence.jdbc.DatabaseType
> org.infinispan.persistence.jdbc.Dialect <ISPN-4211 - org.infinispan.distribution.ch.[Default|Replicated|Sync|TopologyAware|TopologyAware]SyncConsistentHashFactory
> org.infinispan.distribution.ch.impl.[Default|Replicated|Sync|TopologyAware|TopologyAwareSync]ConsistentHashFactory <ISPN-4074
NadirX It's fine to move classes around, but in a mature project it's wise to retain but deprecate the old locations to ensure binary compatibility across releases. The impetus for this JIRA is WildFly 9. I would like to use Infinispan 7 for WF9 clustering, but WF9 is stuck with Hibernate 4.3, which depends on Infinispan 6 - so binary compatibility between 6.0 and 7.0 is essential for me to upgrade.
Moving forward, I've had requests from PM to allow users to upgrade the version of Infinispan in WF/EAP post-release and have it magically work with the rest of WildFly/EAP clustering. This won't work unless binary compatibility is preserved - and WF/EAP references all of the the public classes mentioned in the description.