11:08 a.m.
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?
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.
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.
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
11:43 a.m.
Hi,
2014-09-19 11:08 GMT+02:00 Sanne Grinovero <sanne(a)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.
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.
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.
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.
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?
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:39 p.m.
On 19 September 2014 10:43, Gunnar Morling <gunnar(a)hibernate.org> wrote:
Hi,
2014-09-19 11:08 GMT+02:00 Sanne Grinovero <sanne(a)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?sof...
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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
3498
days inactive
3500
days old
2 comments
2 participants
participants (2)
-
Gunnar Morling -
Sanne Grinovero