Re: [hibernate-dev] JPA Compliance

It was added deprecated. Meaning I added it knowing it would go away and I wanted to avoid users using it. BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA 2.2. Yes there is a longer term aspect as well with 6.0 and beyond. Its specifically the "where the JPA way is questionable" aspect I am asking about. Like to me, it really never makes sense to throw an exception when I close something that is already closed. So how do we handle cases like this? On Thu, Nov 16, 2017 at 1:51 PM Vlad Mihalcea <mihalcea.vlad(a)gmail.com&gt; wrote: > Hi Steve, > > I think that for 5.2 was ok to have the isJpaBootstrap method to avoid > breaking compatibility for the native bootstrap. > For 6.0, maybe it's easier if we just align to the JPA spec where it > makes sense, > and only provide a separation where the JPA way is questionable. > > I noticed that the isJpaBootstrap method is deprecated. Was it intended > to be removed in 6.0? > > Vlad > > On Thu, Nov 16, 2017 at 6:21 PM, Steve Ebersole <steve(a)hibernate.org&gt; > wrote: > >> Part of 5.2 was merging the JPA contracts into the corresponding >> Hibernate >> ones. So, e.g., we no longer "wrap" a SessionFactory in an impl of >> EntityManagerFactory - instead, SessionFactory now extends >> EntityManagerFactory. >> >> This caused a few problems that we handled as they came up. In working >> on >> the JPA 2.2 compatibility testing, I see that there are a few more still >> that we need to resolve. Mostly they relate to JPA expecting exceptions >> in >> certain cases where Hibernate has historically been lenient. E.g., JPA >> says that calling EntityManagerFactory#close on an EMF that is already >> closed should result in an exception. Historically, calling >> SessionFactory#close on a SF that is already closed is simply ignored. >> Philosophical debates aside[1], we need to decide how we want to handle >> this situation such that we can throw the JPA-expected exceptions when >> needed. Do we simply change SF#close to match the JPA expectation? Or >> do >> we somehow >> make SF#close aware of JPA versus "native" use? This latter option was >> the >> intent of `SessionFactoryOptions#isJpaBootstrap` and we can certainly >> continue to use that as the basis of the solution here for other cases. >> >> This `#isJpaBootstrap` flag is controlled by the JPA bootstrap code. So >> if >> the EMF is created in either of the 2 JPA-defined bootstrap mechanisms, >> that flag is set to true. It's an ok solution, but it does have some >> limitations - mainly, there was previously a distinction between SF#close >> being called versus EMF#close being called (they were different classes, >> so >> they could react differently). Therefore, regardless of bootstrap >> mechanism, if the user unwrapped the EMF to a SF, they would always get >> the >> legacy SF behavior. >> >> So long story short, so we want to consider an alternative approach to >> deciding what to do in "some"[2] of these cases? Again, we clearly need >> these to throw the spec-mandated exceptions in certain "strict >> compliance" >> situations. The question really is how to do that. Should we: >> >> 1. just completely change the behavior to align with the spec? >> 2. change the behavior to match the spec *conditionally*, where that >> condition could be: >> 1. `#isJpaBootstrap` >> 2. some setting >> 3. some extension contract >> 4. something else? > > >> >> Thoughts? >> >> >> [1] It's not relevant e.g. that I think JPA is wrong here. We need to >> comply with the spec, at least in certain cases ;) >> >> [2] I say "some" here, because I think the spec is correct in some cases >> - >> for example, I think its clearly correct that a closed EMF throws an >> exception when `#createEntityManager` is called. Personally I think its >> questionable whether closing an already closed EMF should be an >> exception. >> > _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >