[hibernate-dev] OGM on WildFly11 ...
Scott Marlow
smarlow at redhat.com
Wed Oct 21 11:49:28 EDT 2015
On 10/21/2015 10:56 AM, Steve Ebersole wrote:
> Well first...I am not sure why you are passing a custom RegionFactory.
> What does your custom RegionFactory do that is missing in the
> hibernate-infinispan impls?
AS7/WildFly needs to starts the underlying Infinispan cache and add a
PersistenceUnitService service dependency on the CacheService. We
currently extend the
org.hibernate.cache.infinispan.InfinispanRegionFactory. This also
depends on the WildFly clustering/Infinispan configuration settings as well.
It has been years since I tried to use the built in hibernate-infinispan
RegionFactory impls, I don't recall if they work (as is) on WildFly.
>
> There is a lot to this discussion under the covers.
>
> To re-iterate our discussion from f2f... Hibernate is moving toward
> being able to accept a number of forms of config settings: String, Class
> and instance. The idea with the String is that we generally accept
> short-names in addition to FQN. This 3-piece resolution occurs inside a
> Service (org.hibernate.boot.registry.selector.spi.StrategySelector). So
> usually this is nice and clean.
>
> RegionFactory does not fit into this cleanliness though, because by
> convention its ctors accept an argument. The generic StrategySelector
> only works with no-arg ctors. So one option is to update the
> RegionFactory convention to not expect the Properties as a ctor
> argument; we'd leverage the org.hibernate.service.spi.Configurable
> instead post-instantiation. This would require discussion with the
> RegionFactory developers and a major release.
>
> Another option, as you suggest is to allow
> hibernate.cache.region.factory_class to identify a Class reference, in
> addition to just the name (FQN or short-name). We could have it accept
> an instance here, but it would not tie in cleanly with StrategySelector
> because of the ctor arg difference, which means I'd end up having to
> duplicate code.
>
> Yet another option would be to allow Jipijapa to explicitly register
> org.hibernate.boot.registry.selector.StrategyRegistration with the
> EntityManagerFactoryBuilder. We have discussed this in the past for
> other things. A StrategyRegistration is a way to hook into the process
> done by StrategySelector. So you'd pass EntityManagerFactoryBuilder a
> StrategyRegistration that registers the resolution of the name you want
> for your RegionFactory to its Class. This would in fact be the Class
> reference.
+1, StrategyRegistration sounds like the cleanest solution (IMO).
>
> Or of course, to the first questions I asked.. you could also use one of
> the hibernate-infinispan impls.
>
>
>
> On Wed, Oct 21, 2015 at 9:14 AM Scott Marlow <smarlow at redhat.com
> <mailto:smarlow at redhat.com>> wrote:
>
> Hi,
>
> After our discussion last week about improving OGM use on WildFly (by
> adding a Jipijapa integration adapter for OGM), I wanted to share some
> feedback.
>
> A few years ago, we decided that having a 1-1 (bidirectional) dependency
> between ORM + the Jipijapa adapter was okay. With OGM, we need to
> discuss again. I think that our choices are to update ORM properties
> that identify class names, to also allow a class instance to be
> specified. This doesn't have to be all ORM integration properties but
> likely should include the ones currently set by Jipijapa.
>
> hibernate.cache.region.factory_class is currently used by Jipijapa to
> specify the name of the cache region factory class name. I think this
> implies that the Hibernate ORM classloader will need access to the
> Jipijapa supplied class (as mentioned above). Currently, in WildFly 10,
> the ORM module (org.hibernate:main) depends on the
> org.hibernate.jipijapa-hibernate5:main module to resolve this class.
>
> Some alternatives to changing hibernate.cache.region.factory_class to
> allow a class to be specified:
>
> 1. OGM could bundle the ORM classes or depend on a duplicate ORM module
> (with a dependency on a jipi_ogm module).
>
> 2. OGM could avoid using the 2lc on WildFly.
>
> Any preferences or suggestions?
>
> Scott
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
More information about the hibernate-dev
mailing list