[hibernate-dev] OGM on WildFly11 ...

[Scott Marlow]

On 10/21/2015 11:43 AM, Sanne Grinovero wrote:
> 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.

I was actually thinking runtime, not compile time.

>
> 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 for explaining, this makes sense.

>
> 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