[hibernate-dev] JPA Compliance

[Vlad Mihalcea]

Where the JPA way is questionable, let's add one configuration:
hibernate.jpa.compliance with multiple modes:

- strict: we do whatever the JPA standard says we should do, like throwing
an exception when trying to close the EMF twice
- native: we bend the rule where we don't agree with the standard

Maybe we should expose all those cases and group them in some interface to
allow the user to customize the level of compliance they need.

Vlad

On Thu, Nov 16, 2017 at 10:06 PM, Steve Ebersole <steve at hibernate.org>
wrote:

> 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
>>>
>>
>>