[hibernate-dev] What's the identity of Hibernate OGM's "public API" module?

Tue May 3 15:32:43 EDT 2016

On 05/03/2016 09:37 AM, Sanne Grinovero wrote:
> Hi Scott,

Hi Sanne,

>
> sorry for the delay, we finally discussed this over chat.

Thanks for catching up on this.

>
> We decided to start producing Hibernate OGM modules which include a
> Version identification in the slot name. For now we'll also include an
> alias to resolve "main" to the new format, so WildFly won't break yet.

>
> But for the future we think that it would be best to have WildFly not
> depend on the "main" slot automatically, at least until WildFly
> doesn't include a version of OGM.

Do you mean "does", instead of "doesn't"?

WildFly currently doesn't include a version of OGM but I would like to 
change that.

> If we eventually agree to include OGM superpowers within WildFly, then
> that version will be named "main" and jipijapa could default to that.

The sooner that we have a WildFly topic branch with OGM integrated, the 
better.  I've been pushing on native OGM client integration via a 
WildFly topic branch [1] and would like to do something similar for OGM 
integration (either via [1] or a new WildFly topic branch).

By the way, it is really the WildFly JPA container, rather than jipijapa 
that defaults the module name (including slot), based on the persistence 
provider class name mentioned in the persistence.xml.

I think that some pending questions for OGM on WildFly, are:

1. Do we need a subsystem to manage deployment of OGM applications?  Or 
can we rely on the JPA container deployment in WildFly to deploy OGM 
applications?  By default, I don't think we need a separate OGM 
subsystem, but I might not yet understand all of the requirements.

2. Will the (WildFly) existing Hibernate ORM jars be used by the WildFly 
OGM module or will OGM have its own copy of the ORM jars?

3. Will the OGM module dependencies be the same as ORM [2]?

4. Does the OGM module still need to export certain classloaders to 
applications?  From earlier conversations, I think that we talked about 
the exported dependencies varying based on which OGM backend is 
targeted. I'm not sure how we can handle that yet.

5. Pending from earlier discussions, we would like to have a jipijapa 
module that is specific for OGM.  Perhaps jipijapa could be extended to 
help with classloader magic (4).

>
> Until that day comes, we'd prefer it if you could disable this
> functionality of Jipijapa, or maybe expect a (required?) property to
> have the user explicitly state which version should be used.

I'd like to start planning how everything needed, will/when align 
together.  Soon, we should at least get some feedback on the WildFly dev 
ml, on OGM in WildFly (I plan to post soon) and hope that we can have 
some overlapping discussion there as needed (about NoSQL integration).

Thanks,
Scott

[1] https://github.com/scottmarlow/wildfly/tree/nosql-dev8 (will likely 
start a nosql-dev9 branch when I squash commits next time).  Let me know 
if you there is interest in reviewing this branch and I'll squash right 
away (easier to review squashed commits imo).

[2] http://pastie.org/10822811

>
> Thanks,
> Sanne
>
>
> On 21 April 2016 at 14:59, Scott Marlow <smarlow at redhat.com> wrote:
>>
>>
>> On 04/18/2016 11:32 AM, Sanne Grinovero wrote:
>>>
>>> I think there was some confusion in this thread, probably it wasn't
>>> clear that WildFly 10 already does inject automatically OGM, and that
>>> ship sailed so we have to keep in mind what Jipijapa is going to do by
>>> default:
>>>
>>> The current state in WildFly 10's deployers is very simple: if it
>>> "sees" that the persistence.xml is defining a Persistence Provider
>>> named "org.hibernate.ogm.jpa.HibernateOgmPersistence", then it will
>>> look for a module named "org.hibernate.ogm" and inject this to the
>>> classpath. That does imply slot "main" is expected to be available.
>>> This logic can be overriden, but it requires the user to specify - and
>>> know about - additional configuration properties.
>>
>>
>> If the slot is not "main", the application will use
>> "jboss.as.jpa.providerModule" to specify the corrected module name.  If
>> users need a "jboss.as.jpa.providerModuleSlot" option, that could be added.
>>
>>>
>>> We can try deciding what we want WildFly 11+ to do better in the
>>> future, but we need to decide at high priority what approach to use
>>> for OGM 5.0.0.Final, given the WildFly-was-released restriction.
>>
>>
>> Is there going to be one static OGM module for all targeted backends? Will
>> the one static OGM module have its own ORM jars or depend on the ORM jars
>> that WildFly packages?
>>
>> From our previous discussion, there are some OGM dependencies expected to
>> leak into the application as well (perhaps via a Jipijapa extension, if we
>> need a OGM integration layer in WildFly).
>>
>>
>>>
>>> Now to reiterate the problem I mentioned in the first email of this
>>> thread: having just the right version of "org.hibernate.ogm" isn't
>>> good enough as one needs the specific dialect modules too.
>>> I asked (teasing) if you all could see the specific dialect options as
>>> power-user extensions, but it seems the consensus is that these are
>>> not really optional.
>>>
>>> So I guess I agree with Gunnar and Davide: [in current WildFly] one
>>> will need to use the jboss-deployment-structure.xml or the Manifest to
>>> make use of OGM, and we'll have to ignore the fact that when one of
>>> these is missing the WildFly deployer will get mad as OGM:main can't
>>> be found.
>>
>>
>>
>>>
>>> More inline:
>>>
>>> On 31 March 2016 at 11:48, Gunnar Morling <gunnar at hibernate.org> wrote:
>>>>
>>>> So I think for the time being I'd be fine if WF didn't add anything
>>>> implicitly at all for OGM.
>>>
>>>
>>> Too late, hope that's clear now.
>>>
>>>> The reason being, that OGM is not (yet) part of WF, the user needs to put
>>>> in
>>>> the modules from the ZIP themselves. So it seems acceptable to me to add
>>>> the
>>>> dependencies to the required modules by hand (matching the slot of the
>>>> modules they unzipped).
>>>
>>>
>>> Yes, acceptable for the time being, but for a future version of WF it
>>> would be nice to not have users create (and learn about) yet another
>>> configuration file.
>>>
>>>> Should WF do it automatically, some logic along these lines would be
>>>> needed:
>>>>
>>>> * If OGM is the persistence provider and there is only one set of OGM
>>>> modules available, add all the OGM modules actually present (e.g. the
>>>> user
>>>> could have unzipped only core and one of the backends); Optionally, only
>>>> add
>>>> those backend(s) actually in use as per the configuration
>>>> * If more than one set of OGM modules is available, require the user to
>>>> explicitly specify the slot
>>>>
>>>> How about doing this once OGM actually is part of WF? Then one could
>>>> default
>>>> to the provided version, requiring the override only if the user wishes
>>>> to
>>>> use (and provides) another version.
>>>
>>>
>>> +1 but to eventually allow WF to pick a specific OGM slot, we should
>>> first release versioned modules.
>>>
>>> I initially thought that we could provide an alias module "main ->
>>> current release" to have the jipijapa integration work in certain
>>> circumstances, but realising that the dialect-specific modules are
>>> needed too, I guess this would be pointless.
>>>
>>> So my plan is to simply switch our released modules to a specific
>>> slot, then update the documentation accordingly. Not sure how far
>>> jipijapa will try to stop me :) we might need additional JPA
>>> properties too to override it.
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>>
>>>>
>>>> --Gunnar
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>