[hibernate-dev] OGM on WildFly11 ...

[Sanne Grinovero]

On 21 October 2015 at 16:37, Scott Marlow <smarlow at redhat.com> wrote:
>
>
> On 10/21/2015 10:48 AM, Sanne Grinovero wrote:
>>
>> Hi Scott,
>> I would prefer to have ORM accept instances, and so not need the
>> bi-directional dependency across modules.
>>
>> Hibernate OGM already bundles/depends on some ORM classes but it would
>> be much better for everyone if we could keep flexibility about which
>> versions exactly.
>>
>> Regarding 2LC: is the RegionFactory the only thing which is currently
>> being injected as classname rather than instance?
>
>
> Yes, that is the only classname setting that Jipijapa depends on currently.
>
>> If so I think this would be acceptable for a first preview version,
>> but I'd still prefer we could clean that up soon.
>
>
> We could start by not specifying the RegionFactory in the Jipijapa-OGM.
>
>>
>> In terms of module dependencies: Jipijapa/OGM should depend on a (user
>> selectable) slot of Hibernate OGM. The Hibernate OGM module will
>> export the dependency of Hibernate ORM which it targets, so the
>> Jipijapa/OGM module would not need to depend directly on any ORM
>> module.
>
>
> As of yet, I don't think that Jipijapa-OGM needs to depend directly on any
> OGM classes (biggest initial improvement is to specify the SCANNER so we
> automatically recognize entity classes in VFS based deployments).

You're talking about compile time: yes you should be able to compile
Jipijapa-OGM by simply having Maven point to the correct version of
Hibernate ORM.

But I'm pointing out that the module XML definition should *not*
depend on the hibernate-orm main slot, but only to the slot containing
the configured Hibernate OGM module:
this way the OGM module packager can specify which ORM version to use,
and export that to clients like jipijapa-ogm and/or end users.

Thanks,
Sanne

>
>
>>
>> Thanks,
>> Sanne
>>
>>
>>
>> On 21 October 2015 at 15:14, 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