JtaPlatform can already be injected by instance. In general, depending on the service initiator, most services can be specified as either name, Class or instance. Many configuration values as well.
That's something I have been doing for years. On Mon, Apr 4, 2016, 7:57 AM Sanne Grinovero <sa...@hibernate.org> 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? > > 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