Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility
On Tue, May 29, 2018 at 8:38 AM Scott Marlow <smarlow(a)redhat.com> wrote:
On 05/29/2018 08:48 AM, Steve Ebersole wrote:
> By "non-jpa container managed deployments" you mean injecting Hibernate
> Sessions? Otherwise, I am not sure what this is supposed to mean. Nor
> why it is a differentiator in how we use JtaPlatform
/ JtaPlatformInitiator.
Applications that deploy on WF, will use the WildFly
JtaPlatformInitiator, unless they add a persistence unit hint
"wildfly.jpa.jtaplatform" set to "false", in which case the WildFly
JtaPlatformInitiator will not be added for the deployment. We added
this for allowing applications to have more control over which
JtaPlatform is used (e.g. they can use an app configured JtaPlatform or
the determined correct ORM JtaPlatform).
Well that may be how your jipijapa works. That's not how mine works. I
really wish we would keep this code in sync, or if you could use
hibernate-jipijapa. Maybe you mean against 5.1?
Anyway, in hibernate-jipijapa I simply extend the normal
`JtaPlatformInitiator` and override `#getFallbackProvider`. The way that
should work is that it will prefer any value explicitly set by the user;
but, if they do not specify anything explicitly, I use the "fallback". At
least that is how it should work - if it does not, I would consider that a
bug and we should fix it.
Or if you mean against 5.1 or an earlier version... the only difference is
the inclusion of the explicit `#getFallbackProvider` hook - you can still
effect the same change simply by fully implementing
`JtaPlatformInitiator#initiateService`
I do see that Hibernate ORM will always succeed to use the
JBossAppServerJtaPlatform on WF, since we will only try using the
JBossStandalone if the JNDI lookup of the WF TM fails.
Sure, because you are not telling it to do anything different with an
initiator.
What happens if the deployment, is configured to use
JBossStandAloneJtaPlatform directly on WF? I assume they will need
to
switch to use our new WildFlyStandAloneJtaPlatform class on ORM 5.3.2,
so that the app sees correct JTA TX status?
Nope, on 5.3 hibernate-jipijapa simply works. You have problems because
you are not following that paradigm.
There is also now the problem that in 5.3.1,
JBossStandAloneJtaPlatform
referred to the WildFly Transaction Client but is now reverted in 5.3.2,
to only refer to the Arjuna classes. Perhaps instead in 5.3.2, we
should delete WildFlyStandAloneJtaPlatform and merge the logic into the
existing JBossStandAloneJtaPlatform (so that we first check for WildFly
Transaction Client classes, failing that, we then try the Arjuna classes.)
I agree that this is a problem and should not have been changed. At least
without looking. IMO JBossStandAloneJtaPlatform ought to look for any of
the classes it can use.