[hibernate-dev] JPA Compliance
Steve Ebersole
steve at hibernate.org
Thu Nov 16 15:06:38 EST 2017
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 at gmail.com>
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 at hibernate.org>
> 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
More information about the hibernate-dev
mailing list