On Tue, May 29, 2018 at 8:38 AM Scott Marlow <smar...@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. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
