[hibernate-dev] 6.0 planning

[Scott Marlow]

Hmm, just searched through irc history and came up with fixed by 
https://hibernate.atlassian.net/browse/HHH-7552.  Nice to see this 
already fixed!  ;)

On 04/04/2016 10:32 AM, Steve Ebersole wrote:
> 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
> <mailto: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
>     <mailto: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
>     <mailto: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
>     <mailto:hibernate-dev at lists.jboss.org>
>      >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>      >>>
>      >> _______________________________________________
>      >> hibernate-dev mailing list
>      >> hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>      >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     _______________________________________________
>     hibernate-dev mailing list
>     hibernate-dev at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>