[hibernate-dev] OGM on WildFly11 ...

[Steve Ebersole]

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?

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.

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> 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
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>