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

On 19 September 2014 10:43, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: Thanks 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). 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. 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. 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