11:15 a.m.
I'm reviewing how we expect people to use the Hibernate OGM modules on WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
-
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
See the difference? We expect people to explicitly import he couchdb module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.
Thanks,
Sanne
12:35 p.m.
I don't think I like the idea of adding unnecessary dependencies on the
user classpath.
If I understand correctly, you would add a lot of dependencies to avoid
adding:
org.hibernate.ogm.couchdb service
I think this is something that a "Basic user" can handle.
I don't think it's worth to work for another solution that we don't plan to
use in the long term.
My preference goes to C, the user already has to set
hibernate.ogm.datastore.provider, I think it would be nice to use the same
property to
know which module we need.
To clarify to others, for using CouchDB, the user already has to set the
property:
hibernate.ogm.datastore.provider = couchdb_experimental
There are constants for each available datastore:
ehcache, infinispan, mongodb, ...
On Wed, Mar 30, 2016 at 5:15 PM, Sanne Grinovero <sanne(a)hibernate.org>
wrote:
I'm reviewing how we expect people to use the Hibernate OGM
modules on
WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
-
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
See the difference? We expect people to explicitly import he couchdb
module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:50 p.m.
On 30 March 2016 at 18:35, Davide D'Alto <davide(a)hibernate.org> wrote:
I don't think I like the idea of adding unnecessary dependencies
on the user
classpath.
I don't like it either, but specifically why not?
It would be less "magic" which is usually a good thing in these complex
systems.
If I understand correctly, you would add a lot of dependencies to
avoid
adding:
org.hibernate.ogm.couchdb service
I think this is something that a "Basic user" can handle.
I don't think it's worth to work for another solution that we don't plan to
use in the long term.
I'm not sure how to interpret you: are you voting against option B, or
voting against doing any change?
It's not about having the user to have to type just "org.hibernate.ogm
services", rather than "org.hibernate.ogm services,
org.hibernate.ogm.couchdb services" :
it's about the user not needing to add any Manifest, any XML nor
having to read 5 pages of reference documentation about details of
modules configuration in WildFly.
So my proposals are about how to close the final step, so we can remove it all.
My preference goes to C, the user already has to set
hibernate.ogm.datastore.provider, I think it would be nice to use the same
property to
know which module we need.
To clarify to others, for using CouchDB, the user already has to set the
property:
hibernate.ogm.datastore.provider = couchdb_experimental
There are constants for each available datastore:
ehcache, infinispan, mongodb, ...
Sure, some logic could read out properties, that's C1. The problem for
me is that if this logic is hardcoded in WildFly we're stuck with the
modules it supports and we can't add new dialects in new releases of
OGM.
To implement C/2 I suspect we'll need to expose some contract which
allows us to select it, and JipiJapa/OGM will have to invoke that.. so
at least the contract API needs to be stable in the long term.
Thanks,
Sanne
3:11 p.m.
On 03/30/2016 12:15 PM, Sanne Grinovero wrote:
I'm reviewing how we expect people to use the Hibernate OGM
modules on WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
-
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
Which classloader needs access to CouchDB? Will the application code
contain references to CouchDB because OGM is used by the application?
Or will the OGM (org.hibernate.ogm) module contain references to CouchDB?
See the difference? We expect people to explicitly import he couchdb
module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a specific version,
or at least allow overrides like we do with Search.
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
7:58 p.m.
On 30 Mar 2016 21:11, "Scott Marlow" <smarlow(a)redhat.com> wrote:
On 03/30/2016 12:15 PM, Sanne Grinovero wrote:
>
> I'm reviewing how we expect people to use the Hibernate OGM modules on
WildFly.
>
> Scott mentioned that the JPA subsystem of WildFly automatically adds
> the "org.hibernate.ogm" module when the
> org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
> set.
>
> See also :
> -
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
>
> OGM's reference documentation recommends to add the modules depending
> on which backend is being used, i.e. for CouchDB:
>
> org.hibernate.ogm services, org.hibernate.ogm.couchdb services
>
Which classloader needs access to CouchDB? Will the application code
contain
references to CouchDB because OGM is used by the application? Or
will the OGM (org.hibernate.ogm) module contain references to CouchDB?
Both.
The underlying datastore is not fully abstracted.
> See the difference? We expect people to explicitly import he couchdb
module
too.
> We essentially expect people to use a different API - i.e. a
different
> classpath - depending on the storage.. that's unusual.
> The traditional answer is that you should have one API, but our case
> is a bit more complex so let's see the options.
>
> I'd like to get rid of the need specify modules. I see several paths,
> some less compelling:
>
> A- consider the "couchdb" module a non-essential, power users only
> API which you can only unlock by manually configuring modules.
> pros: it's done :)
> cons: would we agree that OGM is still compelling even without
> those "options" for a majority of basic users?
>
> B- have WildFly inject all these modules on the user's classpath
> pros: consistency, no magic, everyone gets the same.
> cons: Requires updates in WildFly to support new datastores. Larger
> classpath? More conflict potentials? More stuff to "support" ?
>
> C/1- have WildFly "guess" the right dependency set by looking at
> additional properties.
> pros: exposes the minimum but not less
> cons: requires such logic to be defined in JipiJapa, needs long
> term stability, needs to deal with multiple (different) PU
> configurations.
>
> C/2- have WildFly invoke some helper of ours which defines the
> modulesets we want
> pros: we can control and evolve this as we realise which mistakes
> we're making :)
> cons: more complex to define this contract?
>
>
> My vote goes to B, at least for the short term. C/2 is my favourite in
> the longer term, or at least a B which allows us to define new
> datastores without needing changes in WildFly.
>
> Orthogonal to this, but to keep in mind: WildFly also injects the
> "main" slot exclusively. We'll need a way to pick a specific version,
> or at least allow overrides like we do with Search.
>
> Thanks,
> Sanne
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
1:39 a.m.
2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
I'm reviewing how we expect people to use the Hibernate OGM
modules on
WildFly.
Scott mentioned that the JPA subsystem of WildFly automatically adds
the "org.hibernate.ogm" module when the
org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
set.
See also :
-
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
OGM's reference documentation recommends to add the modules depending
on which backend is being used, i.e. for CouchDB:
org.hibernate.ogm services, org.hibernate.ogm.couchdb services
See the difference? We expect people to explicitly import he couchdb
module too.
We essentially expect people to use a different API - i.e. a different
classpath - depending on the storage.. that's unusual.
That has been an explicit choice; Different stores e.g. expose different
mapping strategies and configuration options. There are annotations and a
fluent API which live in the respective modules, allowing the user to
configure these specifics in a safe way. Instead of exposing the super set
of all these specifics from all stores in one common API, we pushed these
specifics to the backend modules (with some re-use within a type of store,
say document stores, where it made sense).
The traditional answer is that you should have one API, but our case
is a bit more complex so let's see the options.
I'd like to get rid of the need specify modules. I see several paths,
some less compelling:
A- consider the "couchdb" module a non-essential, power users only
API which you can only unlock by manually configuring modules.
pros: it's done :)
cons: would we agree that OGM is still compelling even without
those "options" for a majority of basic users?
No, that's not really feasible. Users need to be able to access these store
specifics.
B- have WildFly inject all these modules on the user's classpath
pros: consistency, no magic, everyone gets the same.
cons: Requires updates in WildFly to support new datastores. Larger
classpath? More conflict potentials? More stuff to "support" ?
C/1- have WildFly "guess" the right dependency set by looking at
additional properties.
pros: exposes the minimum but not less
cons: requires such logic to be defined in JipiJapa, needs long
term stability, needs to deal with multiple (different) PU
configurations.
C/2- have WildFly invoke some helper of ours which defines the
modulesets we want
pros: we can control and evolve this as we realise which mistakes
we're making :)
cons: more complex to define this contract?
My vote goes to B, at least for the short term. C/2 is my favourite in
the longer term, or at least a B which allows us to define new
datastores without needing changes in WildFly.
Yes, C/2 would be nice to have.
Although I don't see a big issue in demanding to add a specific module
dependency. It's documented and I don't think I remember any user report
complaining about it. People also add dependencies to their Maven POM :)
Another question is how to deal with backends not part of the "official"
OGM package. Would users have to fall back to the explicit dependency for
those?
Orthogonal to this, but to keep in mind: WildFly also injects the
"main" slot exclusively. We'll need a way to pick a
specific version,
or at least allow overrides like we do with Search.
That's the beauty of manual configuration: People can select the slot they
want :) Right now I don't see a huge benefit in replacing one property in
the manifest with another property in persistence.xml.
All in all I feel it might be a nice improvement, but I don't think its
impact is huge.
Thanks,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
4:09 a.m.
Although I don't see a big issue in demanding to add a specific
module
dependency. It's documented and I don't think I remember any user report
complaining about it. People also add dependencies to their Maven POM :)
+1
On Thu, Mar 31, 2016 at 7:39 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
> 2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> > I'm reviewing how we expect people to use the Hibernate OGM modules on
> > WildFly.
> >
> > Scott mentioned that the JPA subsystem of WildFly automatically adds
> > the "org.hibernate.ogm" module when the
> > org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
> > set.
> >
> > See also :
> > -
> >
>
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
> >
> > OGM's reference documentation recommends to add the modules depending
> > on which backend is being used, i.e. for CouchDB:
> >
> > org.hibernate.ogm services, org.hibernate.ogm.couchdb services
> >
> > See the difference? We expect people to explicitly import he couchdb
> > module too.
> > We essentially expect people to use a different API - i.e. a different
> > classpath - depending on the storage.. that's unusual.
> >
>
> That has been an explicit choice; Different stores e.g. expose different
> mapping strategies and configuration options. There are annotations and a
> fluent API which live in the respective modules, allowing the user to
> configure these specifics in a safe way. Instead of exposing the super set
> of all these specifics from all stores in one common API, we pushed these
> specifics to the backend modules (with some re-use within a type of store,
> say document stores, where it made sense).
>
>
> > The traditional answer is that you should have one API, but our case
> > is a bit more complex so let's see the options.
> >
> > I'd like to get rid of the need specify modules. I see several paths,
> > some less compelling:
> >
> > A- consider the "couchdb" module a non-essential, power users only
> > API which you can only unlock by manually configuring modules.
> > pros: it's done :)
> > cons: would we agree that OGM is still compelling even without
> > those "options" for a majority of basic users?
> >
>
> No, that's not really feasible. Users need to be able to access these store
> specifics.
>
> B- have WildFly inject all these modules on the user's classpath
> > pros: consistency, no magic, everyone gets the same.
> > cons: Requires updates in WildFly to support new datastores. Larger
> > classpath? More conflict potentials? More stuff to "support" ?
> >
> > C/1- have WildFly "guess" the right dependency set by looking at
> > additional properties.
> > pros: exposes the minimum but not less
> > cons: requires such logic to be defined in JipiJapa, needs long
> > term stability, needs to deal with multiple (different) PU
> > configurations.
> >
> > C/2- have WildFly invoke some helper of ours which defines the
> > modulesets we want
> > pros: we can control and evolve this as we realise which mistakes
> > we're making :)
> > cons: more complex to define this contract?
> >
> >
> > My vote goes to B, at least for the short term. C/2 is my favourite in
> > the longer term, or at least a B which allows us to define new
> > datastores without needing changes in WildFly.
> >
>
> Yes, C/2 would be nice to have.
>
Although I don't see a big issue in demanding to add a specific
module
dependency. It's documented and I don't think I remember any user report
complaining about it. People also add dependencies to their Maven POM :)
>
> Another question is how to deal with backends not part of the "official"
> OGM package. Would users have to fall back to the explicit dependency for
> those?
>
> Orthogonal to this, but to keep in mind: WildFly also injects the
> > "main" slot exclusively. We'll need a way to pick a specific
version,
> > or at least allow overrides like we do with Search.
> >
>
> That's the beauty of manual configuration: People can select the slot they
> want :) Right now I don't see a huge benefit in replacing one property in
> the manifest with another property in persistence.xml.
>
> All in all I feel it might be a nice improvement, but I don't think its
> impact is huge.
>
> Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
5:05 a.m.
On 31 March 2016 at 10:09, Davide D'Alto <davide(a)hibernate.org> wrote:
> Although I don't see a big issue in demanding to add a
specific module
> dependency. It's documented and I don't think I remember any user report
> complaining about it. People also add dependencies to their Maven POM :)
+1
Sure we can keep that requirement of having to explicitly list the dependencies;
what bothers me though, is that WildFly is going to add half of the
needed modules
automatically, AND hardcodes the slot.
That's really not aligned with what we have in our documentation.
So, should we rather ask Scott to remove that OGM support code from WildFly?
I'd rather have WildFly add all the modules, at least people can
forget about this.
Thanks,
Sanne
On Thu, Mar 31, 2016 at 7:39 AM, Gunnar Morling <gunnar(a)hibernate.org>
wrote:
>
> 2016-03-30 18:15 GMT+02:00 Sanne Grinovero <sanne(a)hibernate.org>:
>
> > I'm reviewing how we expect people to use the Hibernate OGM modules on
> > WildFly.
> >
> > Scott mentioned that the JPA subsystem of WildFly automatically adds
> > the "org.hibernate.ogm" module when the
> > org.hibernate.ogm.jpa.HibernateOgmPersistence persistence provider is
> > set.
> >
> > See also :
> > -
> >
> >
https://docs.jboss.org/author/display/WFLY10/JPA+Reference+Guide#JPARefer...
> >
> > OGM's reference documentation recommends to add the modules depending
> > on which backend is being used, i.e. for CouchDB:
> >
> > org.hibernate.ogm services, org.hibernate.ogm.couchdb services
> >
> > See the difference? We expect people to explicitly import he couchdb
> > module too.
> > We essentially expect people to use a different API - i.e. a different
> > classpath - depending on the storage.. that's unusual.
> >
>
> That has been an explicit choice; Different stores e.g. expose different
> mapping strategies and configuration options. There are annotations and a
> fluent API which live in the respective modules, allowing the user to
> configure these specifics in a safe way. Instead of exposing the super set
> of all these specifics from all stores in one common API, we pushed these
> specifics to the backend modules (with some re-use within a type of store,
> say document stores, where it made sense).
>
>
> > The traditional answer is that you should have one API, but our case
> > is a bit more complex so let's see the options.
> >
> > I'd like to get rid of the need specify modules. I see several paths,
> > some less compelling:
> >
> > A- consider the "couchdb" module a non-essential, power users only
> > API which you can only unlock by manually configuring modules.
> > pros: it's done :)
> > cons: would we agree that OGM is still compelling even without
> > those "options" for a majority of basic users?
> >
>
> No, that's not really feasible. Users need to be able to access these
> store
> specifics.
>
> B- have WildFly inject all these modules on the user's classpath
> > pros: consistency, no magic, everyone gets the same.
> > cons: Requires updates in WildFly to support new datastores. Larger
> > classpath? More conflict potentials? More stuff to "support" ?
> >
> > C/1- have WildFly "guess" the right dependency set by looking at
> > additional properties.
> > pros: exposes the minimum but not less
> > cons: requires such logic to be defined in JipiJapa, needs long
> > term stability, needs to deal with multiple (different) PU
> > configurations.
> >
> > C/2- have WildFly invoke some helper of ours which defines the
> > modulesets we want
> > pros: we can control and evolve this as we realise which mistakes
> > we're making :)
> > cons: more complex to define this contract?
> >
> >
> > My vote goes to B, at least for the short term. C/2 is my favourite in
> > the longer term, or at least a B which allows us to define new
> > datastores without needing changes in WildFly.
> >
>
> Yes, C/2 would be nice to have.
>
> Although I don't see a big issue in demanding to add a specific module
> dependency. It's documented and I don't think I remember any user report
> complaining about it. People also add dependencies to their Maven POM :)
>
> Another question is how to deal with backends not part of the "official"
> OGM package. Would users have to fall back to the explicit dependency for
> those?
>
> Orthogonal to this, but to keep in mind: WildFly also injects the
> > "main" slot exclusively. We'll need a way to pick a specific
version,
> > or at least allow overrides like we do with Search.
> >
>
> That's the beauty of manual configuration: People can select the slot they
> want :) Right now I don't see a huge benefit in replacing one property in
> the manifest with another property in persistence.xml.
>
> All in all I feel it might be a nice improvement, but I don't think its
> impact is huge.
>
> Thanks,
> > Sanne
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
5:48 a.m.
So I think for the time being I'd be fine if WF didn't add anything
implicitly at all for OGM.
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).
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.
--Gunnar
10:32 a.m.
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.
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.
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(a)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
8:59 a.m.
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(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
8:37 a.m.
Hi Scott,
sorry for the delay, we finally discussed this over chat.
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.
If we eventually agree to include OGM superpowers within WildFly, then
that version will be named "main" and jipijapa could default to that.
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.
Thanks,
Sanne
On 21 April 2016 at 14:59, Scott Marlow <smarlow(a)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(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
2:32 p.m.
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(a)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(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
3136
days inactive
3170
days old
12 comments
4 participants
participants (4)
-
Davide D'Alto -
Gunnar Morling -
Sanne Grinovero -
Scott Marlow