[hibernate-dev] 6.0 planning

[Steve Ebersole]

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 <smarlow at redhat.com> wrote:

> On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
> > 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?
>
>  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 <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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>