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? If so I think this would be acceptable for a first preview version, but I'd still prefer we could clean that up soon. 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. Thanks, Sanne On 21 October 2015 at 15:14, Scott Marlow <smarlow(a)redhat.com&gt; 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(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

On 21 October 2015 at 15:59, Steve Ebersole <steve(a)hibernate.org&gt; wrote: > As I outlined in my reply, as things stand accepting a String or Class or > instance causes a lot of internal code duplication that I'd obviously like > to avoid. I'd be ok with this if we made RegionFactory convention to not > accept ctor args. Since RegionFactory is a Service, I was expecting there to some standard way to provide this Service by injecting it at bootstrap? It would only need to ignore the property and take the service from the registry. > > > On Wed, Oct 21, 2015 at 9:49 AM Sanne Grinovero <sanne(a)hibernate.org&gt; 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? >> If so I think this would be acceptable for a first preview version, >> but I'd still prefer we could clean that up soon. >> >> 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. >> >> Thanks, >> Sanne >> >> >> >> On 21 October 2015 at 15:14, Scott Marlow <smarlow(a)redhat.com&gt; 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(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

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

> > Thanks, > Sanne > > > > On 21 October 2015 at 15:14, Scott Marlow <smarlow(a)redhat.com&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev

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