[hibernate-dev] Hibernate OGM connecting to JDG's version of Infinispan

[Sanne Grinovero]

On 19 September 2014 10:43, Gunnar Morling <gunnar at hibernate.org> wrote:
> Hi,
>
> 2014-09-19 11:08 GMT+02:00 Sanne Grinovero <sanne at hibernate.org>:
>>
>> Hi all,
>>
>> I didn't try this but I'm wondering if I could use Hibernate OGM with
>> its Infinispan backend to deploy on JBoss EAP6 and use the Infinispan
>> build from JDG 6.
>>
>> Could you make sure this is possible?
>
>
> That's an interesting question, I've filed
> https://hibernate.atlassian.net/browse/OGM-604 for tracking this
> requirement.

Thanks

>>
>>
>> I'm expecting some trouble by the fact that depending on Hibernate
>> *ORM* implicitly or explicitly this will bring along the classpath
>> visibility of the EAP version of Infinispan (which is not the one we'd
>> want to use).
>>
>> For example simply by deploying a JPA based application, we'd get this
>> version of Infinispan as it's exposed to the application so that it
>> could be used as a 2nd level cache implementation.
>
>
> I just had a quick look at the OGM module descriptors we create for EAP and
> WildFly. To my surprise, we bundle Infinispan ourselves for EAP (it's part
> of the OGM core module), whereas we depend on the provided module in
> WildFly.

I guess OGM is aiming at compatibility with the Infinispan version
bundled in Wildfly, so when running on WildFly the provided version is
fine, while on EAP we need to override the system's Infinispan
version.
But this assumes a specific version of WildFly: that was easy enough
when there was only one release but with WildFly 9 coming we might
need modules on it too (depending on the version).

Generally speaking I think we shouldn't bundle our own Infinispan jars
but try to have it download and reuse the modules built and released
by the Infinispan project (since recently they follow our same
strategy, so there will be a modules set available for each version of
Infinispan we need).

>
> Extracting a separate hibernate-ogm-module (as we have it for all other
> dialects) would be the first step IMO to improve the situation. We then
> could create yet another module which depends on the modules provided by the
> JDG distribution you mention below (the dialect would be the same as for
> ISPN, only the module dependencies would differ). Users would enable one or
> the other dialect module for the application.

That's where it gets a bit fishy. I don't like it that we have to
duplicate the dialect module, even though the code is the same. An
alternative but equally ugly solution would be the user to edit the
modules.xml to change the slots as he wishes, but I don't think it's a
good idea to have a "well known" module ID changed depending on need,
it's not supposed to be a configuration file.

An alternative approach would be that the user's app had to bundle the
grid-dialect jar with the application, this way the dialect would be
exposed to the same modules as defined by the user in its own deployer
descriptor, and has an opportunity to specify the slot directly.. but
that's not clean either :-/

Maybe we could use aliases, and our modules depend on a module
identifier which has to be created by the user. But then that would be
a system-wide decision, while the point of modules it to make it
possible for different applications to evolve independently... I don't
know the solution, probably best to discuss this with the WildFly
team.

>
> About the conflict with the ISPN version exposed by ORM you mention, is this
> always the case  or only when enabling 2nd-level caching? I would hope for
> the latter.

Ok so I thought it was always the case, but it turns out my failures
where caused by a different and much simpler problem :)
What actually happens is that Infinispan isn't exposed to the
application using ORM after all, but it is exposed to ORM itself so
that it can eventually load its components via SPIs. I fear that -
depending on how OGM is booting exactly - some of its components might
be loaded from this same context, so exposing the ORM module
classloader which does have access to Infinispan slot "wrong".
I guess the good news is that we're in control of such situations, but
it needs extensive testing to make sure we always use the correct
classloaders in both OGM and ORM codebase for this purpose.

>> To clarify: the JDG distribution is packaged as a set of JBoss Modules
>> so you can "layer" them on top of EAP without replacing the Infinispan
>> & co jars included  by the applications server for internal purposes
>> like session clustering and Hibernate caching.
>
>
> Can one get that distribution e.g. as Maven dependency?

Yes but not in a convenient way for CI to access it automatically: you
have to download the tarball of the whole Maven repository from the
Red Hat support portal:
 - https://access.redhat.com/jbossnetwork/restricted/softwareDetail.html?softwareId=31673&product=data.grid&version=6.3.0&downloadType=distributions
Which requires a login to accept T&C .. but we can of course download
it once and unzip on the ci servers.

Cheers,
Sanne

>>
>>
>> OGM is for me just one possible case, ultimately we need to make sure
>> that people using Hibernate can use alternative versions of Infinispan
>> as well, and not be locked into a specific version by the simple fact
>> of using JPA: I'm having the same nasty problem with Search: unable to
>> use JDG for index storage.
>>
>> Sanne
>
>
> --Gunnar
>
>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>