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 <smar...@redhat.com > <mailto:smar...@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@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
