Ok, so we aren't accepting a Class reference or instance for L2C RegionFactory? Is there a Jira for that?
On Mon, Apr 4, 2016 at 9:20 AM Scott Marlow <smar...@redhat.com> wrote: > On 04/04/2016 08:55 AM, Sanne Grinovero wrote: > > On 4 April 2016 at 12:59, Gunnar Morling <gun...@hibernate.org> wrote: > >> One minor wish I'd have around bootstrapping: > >> > >> Can we make the initiators of services residing in the session factory > >> service registry discoverable by means of a ServiceContributor as it's > >> happening for services living in the standard registry? > > > > +1 > > And this reminds me that it would be nice for some services, i.e. the > > JTA Platform, to be injected as an instance rather than as a String > > pointing to the fully qualified classname. > > > > WildFly would benefit from it to override some services without having > > to add them to the Hibernate ORM classpath, and it might help with > > bootstrap speed too. > > > > Scott, AFAIR this was your great idea. Is there a JIRA for it, or > > could you create one for 6? > > From an earlier discussion: > > " > 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. > " > > Steve made similar changes for other properties (years ago I think) but > not all properties were updated to allow class instances to be specified > (in addition to class name). So, it was really Steve Ebersole's great > idea, not mine :) > > > > > Thanks, > > Sanne > > > >> > >> Currently, it's a hard coded list, requiring Hibernate OGM to provide > its > >> own SessionFactoryServiceRegistryFactory implementation which I believe > >> does not fly when it comes to several integrators seeking to provide > their > >> own SF-scoped services. > >> > >> Thanks, > >> > >> --Gunnar > >> > >> > >> > >> 2016-03-31 13:57 GMT+02:00 Steve Ebersole <st...@hibernate.org>: > >> > >>> We have been having a few side discussions about plans for 6.0, and I > >>> thought it would be a good idea to consolidate them together. > >>> > >>> > >>> 1. Incorporate the SQM work. Lots of pieces go into this: > >>> 1. Replacing the interpretation of HQL/JPQL and Criteria > queries. > >>> 2. *Possibly* leveraging SQM to deal with entity operations > >>> (load-by-id, merge, etc). > >>> 3. Improved Query contracts > >>> 4. Improved persister contracts (including addition of an > "embeddable > >>> persister"). > >>> 5. Improved Type contracts > >>> 2. Extensions to JPA criteria based on SQM work(this is probably > more on > >>> ongoing 6.x task) > >>> 3. Baseline on Java 8 > >>> > >>> Is there anything else anyone wants to discuss getting included? > >>> > >>> Another one I'd like to discuss is the consolidation of the > hibernate-core > >>> and hibernate-entitymanager modules into a single module (possibly > renamed > >>> hibernate-orm). There are a lot of reasons and benefits to doing this: > >>> > >>> 1. A major one would be the consolidation of "type systems". > Hibernate > >>> has org.hibernate.type.Type. JPA defines javax.persistence.Type. > Now > >>> with > >>> SQM we have a 3rd type system in play. > >>> 2. It is also the major hurdle to moving to being able to fully > replace > >>> the legacy criteria with JPA criteria. If Session and > EntityManager (as > >>> well as SessionFactory ad EntiytManagerFactory) were fully > integrated > >>> then > >>> Session would be able to build/handle JPA criteria queries. > >>> 3. Simplified HEM bootstrapping > >>> > >>> > >>> There are also a few challenges to doing this consolidation of the > >>> hibernate-core and hibernate-entitymanager modules. The big one tht > stick > >>> out in my head is event-listener with different behaviors between core > and > >>> hem. > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > >> _______________________________________________ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
