9:48 a.m.
So there we go :)
On Mon, Apr 4, 2016 at 9:37 AM Scott Marlow <smarlow(a)redhat.com> wrote:
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(a)redhat.com
> <mailto:smarlow@redhat.com>> wrote:
>
> On 04/04/2016 08:55 AM, Sanne Grinovero wrote:
> > On 4 April 2016 at 12:59, Gunnar Morling <gunnar(a)hibernate.org
> <mailto:gunnar@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(a)hibernate.org
> <mailto:steve@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(a)lists.jboss.org
> <mailto:hibernate-dev@lists.jboss.org>
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org <mailto:
hibernate-dev(a)lists.jboss.org>
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>