[infinispan-dev] Backwards compatibility issues with Infinispan 9.x and Hibernate 2LC

[Sanne Grinovero]

Have fun with the rewriting!
;)

More seriously, it might be worth to have a second module for Hibernate ORM
5.x to address Infinispan 9?
At least in depth testing, stressing and performance aspect won't be left
to the last minute integration step.

Also, would it be worth to move such code to Infinispan? In such cases
neither repository is ideal, but I'd tend to prefer to integrate with the
one which has the more stable and well defined integration point.
Historically that has been Hibernate, so hosting this code closer to
Infinispan and then merely integrate with Hibernate would have been useful.

Alternatively, let's see if we can embrace JCache all-in. The architecture
I had discussed with Alex Snaps for the Hibernate /JCache integration would
allow for "vendor specific extensions" to bypass the spec on some specific
points as needed.


On 16 Feb 2017 11:00, "Galder Zamarreño" <galder at redhat.com> wrote:

> Hi all,
>
> As I've mentioned, I'm working on trying to integrate Hibernate 2LC (5.x
> branch at the moment) with Infinispan 9.
>
> To start with, I tried to see if I could just run Hibernate 2LC 5.x,
> compiled with Infinispan 8, with an Infinispan 9 runtime. The first problem
> here was to do with changes to PrioritizedMethodMetadata [1].
>
> However, that above is the least of our problems... once I tried to
> compile with Infinispan 9, there are a lot of compilation errors.
>
> Here's a list of what I've found out so far, based on the work in [2]
> which includes compilation errors and runtime issues I've discovered:
>
> 1. Plenty of interceptors have been moved from org.infinispan.interceptors.base
> and org.infinispan.interceptors packages to org.infinispan.interceptors.impl
> package.
>
> 2. ModuleCommandFactory.fromStream now passes a cache name in ByteString
> instead of String.
>
> 3. DataWriteCommand.setMetadata() method is gone. The reason for this is
> that FlagAffectedCommand does no longer extend MetadataAwareCommand.
>
> 4. Interceptors cannot invoke invokeNextInterceptor() any more in parent,
> the method has been renamed to invokeNext() (in different class,
> AsyncInterceptor)
>
> 5. A lot of interceptors now take flags as long instead of Set<Flag> which
> results in compilation error.
>
> 6. BaseRpcInterceptor subclasses are now force abstract protected method
> getLog() to be implemented, again a compilation error.
>
> 7. CallInterceptor no longer contains visit... methods, so all
> interceptors extending it need to extend CommandInterceptor and be placed
> just before CallInterceptor.
>
> 7.1. As a result of that, interceptor positioning calls need to be changed.
>
> 8. AdvancedCache.filterEntries() is gone, so need to find an alternative
> way to do the same.
>
> 9. WriteCommand.getAffectedKeys() returns Collection instead of Set now.
>
> 10. org.infinispan.filter.NullValueConverter is gone. I removed that as
> part of marshalling changes since it was not used anywhere within
> Infinispan repo, but Hibernate 2LC actually uses it.
>
> 11. BeginInvalidationCommand and EndInvalidationCommand write directly the
> lockOwner via `output.writeObject(lockOwner)`, but this causes problem
> when the lockOwner is a CommandInvocationId since there's no externalizer
> for it any more. The reason for not having an externalizer is that
> CommandInvocationId is written via static CommandInvocationId.writeTo()
> calls.
>
> 12. org.infinispan.commands.module.ExtendedModuleCommandFactory is gone.
>
> 13. ReplicableCommand.setParameters() method is gone.
>
> 14. BaseRpcCommand constructor takes a ByteString instead of String.
>
> 15. ReplicableCommand implementations need to implement writeTo() and
> readFrom() methods.
>
> 16. (test) BlockingInterceptor no longer can be added via
> AdvancedCache.addInterceptor() call because it does not extend
> CommandInterceptor any more.
>
> 17. (test) org.infinispan.util.concurrent.ConcurrentHashSet has been
> moved.
>
> 18. (test) TestingEntityCacheKey must be made extend ExternalPojo so that
> it can be externally marshalled.
>
> 19. (test) 2lc-test-tcp.xml contains attributes that are no longer found
> by JGroups 4.x and throws errors.
>
> The question here is whether we should work towards making Infinispan 9
> backwards compatible with Infinispan 8 as far as Hibernate 2LC integration
> is concerned.
>
> In theory, Infinispan 9 should be integrated with Hibernate 6.x onwards,
> but as always, Wildfly might have different opinions... @Paul?
>
> If we need to do something, the time to do it is now, before 9.Final.
>
> Cheers,
>
> p.s. A lot of tests still failing, so the work in [2] is nowhere near
> finished.
>
> [1] https://gist.github.com/galderz/e26ea9d4838a965500906a6df87e064a
> [2] https://github.com/galderz/hibernate-orm/commit/
> 5e36a021db4eaad75d835d321282eee6c62cc7c6
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20170216/bb13cc6b/attachment.html