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