[hibernate-dev] 6.0 planning

[Sanne Grinovero]

On 4 April 2016 at 12:59, Gunnar Morling <gunnar at 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 <steve at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev