Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Sanne Grinovero]

On 4 June 2018 at 12:23, Tom Jenkinson  wrote:
>
>
> On 28 May 2018 at 12:23, Sanne Grinovero  wrote:
>>
>> On 28 May 2018 at 00:05, Steve Ebersole  wrote:
>> > JBossStandalone is meant for use of JBoss Transactions outside of
>> > WildFly.
>> > Why are we using it inside WildFly.  Inside WildFly, jipijapa ought to
>> > be
>> > defining that however it needs through a custom JtaPlatform and probably
>> > the
>> > JtaPlatformInitiator.
>>
>> I don't know the reasons, as I just started looking at WildFly Swarm
>> (now named Thorntail) and I'm merely reporting I see such exceptions.
>>
>> It's indeed surprising that this JTA Platform is being picked; I
>> chatted with Scott on another chat wondering why this system
>> apparently is not using JipiJapa - which would configure it correctly.
>> I guess it's not clear to me if Thorntail is to be considered "in" or
>> "outside" WildFly but I'm keeping this conversation for the Thorntail
>> team.
>>
>> All I observe is that 5.3.0.Final worked fine in Thorntail while
>> 5.3.1.Final will not work unless I figure out how to reconfigure it or
>> which other dependencies need switching - neither seems trivial and
>> that's unexpected from a micro update.
>> Same for the Narayana quickstarts and demo projects - maybe their
>> configuration could use some updates but I'm not sure, I'll leave that
>> to Tom and Gytis to decide.
>
>
> I just wanted to check, do we need any changes in the Narayana quickstart to
> deal with this? It reads as though since 5.3.2 we don't need to add a new
> dependency?
> https://github.com/jbosstm/quickstart/blob/master/jca-and-hibernate/src/test/resources/META-INF/persistence.xml#L39

Hi Tom,

I'm not sure either, let's test it after 5.3.2.Final is released -
likely we won't need to make any changes to the quickstarts.

@All:
For Hibernate Search, Thorntail, and Infinispan I already did the
upgrade and they come with custom JTA platform providers to dodge the
incompatibility.
The same trick wasn't possible with OGM as we test interactions with
the transaction system in many more subtle ways; I decided it wasn't
worth the effort of introducing all the scaffolding as we can just
wait for ORM 5.3.2 instead.

Thanks,
Sanne

>
>>
>>
>> Thanks,
>> Sanne
>>
>> >
>> >
>> > On Sun, May 27, 2018, 3:58 PM Sanne Grinovero 
>> > wrote:
>> >>
>> >> On 27 May 2018 at 15:29, Scott Marlow  wrote:
>> >> >
>> >> >
>> >> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero
>> >> > 
>> >> > wrote:
>> >> >>
>> >> >> On 27 May 2018 at 00:30, Scott Marlow  wrote:
>> >> >> > Next idea, we should first look for the WFTC classes, if not
>> >> >> > found,
>> >> >> > then
>> >> >> > look for Arjuna classes.
>> >> >>
>> >> >> +1 that would be nice and I see other implementations e.g.
>> >> >> JBossAppServerJtaPlatform have a precedent of attempting multiple
>> >> >> strategies to maintain backward compatibility.
>> >> >>
>> >> >> Created:
>> >> >>  - https://hibernate.atlassian.net/browse/HHH-12640
>> >> >
>> >> >
>> >> > https://github.com/hibernate/hibernate-orm/pull/2314
>> >> >
>> >> >>
>> >> >>
>> >> >>
>> >> >> Regarding the use of the old Arjuna name: you might be right that it
>> >> >> shouldn't be used, but it's still very common:
>> >> >>
>> >> >> even the Narayana quickstarts using Hibernate are broken by this
>> >> >> change, and so is any application running on WildFly Swarm or
>> >> >> Thorntail.
>> >> >>
>> >> >> I suppose something should be improved on their side as well, yet we
>> >> >> should give people time (by making it compatible like you suggested)
>> >> >> and help at least with some documented guidance - the fallback
>> >> >> strategy could log a warning to motivate people to update but IMO we
>> >> >> should start bugging people with such messages only when the other
>> >> >> runtimes and examples ship with the new defaults.
>> >> >>
>> >> >> Hibernate Search also has integration tests with Narayana
>> >> >> (standalone
>> >> >> JTA) and it's not clear to me now which dependencies I should be
>> >> >> changing; I suppose I'll figure it out soon as I need to release it
>> >> >> too :)
>> >> >>
>> >> >> The user experience after this error is quite bad: applications now
>> >> >> simply fail to start with a confusing
>> >> >> "javax.persistence.PersistenceException: No Persistence provider for
>> >> >> EntityManager named XYZ found", we give no better error and no clue
>> >> >> about needing to look into the used transactions implementation.
>> >> >>
>> >> >> Created:
>> >> >>  - https://hibernate.atlassian.net/browse/HHH-12639
>> >> >>
>> >> >> Thanks,
>> >> >> Sanne
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > On Sat, May 26, 2018, 7:12 PM Scott Marlow 
>> >> >> > wrote:
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow 
>> >> >> >> wrote:
>> >> >> >>>
>> >> >> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>> >> >> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup
>> >> >> >>> using

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Steve Ebersole]

The implementation from hibernate-jipijapa returns disabling caching at all
if the user did not specify any value.  That was what you wanted to happen
per our discussion at that time.  Really I can make it do whatever you want
- just not sure of a better answer.

Also the point of a "fallback" is what happens when the user does not
explicitly specify.  That is what both the RegionFactoryInitiator and
JtaPlatformInitiator in hibernate-jipijapa do

On Tue, May 29, 2018 at 12:49 PM Scott Marlow  wrote:

>
>
> On 05/29/2018 10:05 AM, Steve Ebersole wrote:
> > On Tue, May 29, 2018 at 8:38 AM Scott Marlow  > > 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?
>
> I think we both agreed that for now, we should maintain the jipijapa
> code in WF, with a fork being kept in ORM, for testing and other
> purposes (like making a new ORM version available to already shipped WF
> versions).
>
> I agree that we should sync our copies of this code, just not sure of
> how, other than discussing a comparison and picking which changes should
> be merged to the other copy.
>
> >
> > 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.
>
> Interesting, should RegionFactoryInitiator also support automatic
> "fallback" to the user configured region factory?  I assume not since we
> are enabling the second level cache on Hibernate ORM but currently are
> not able to do that in WildFly (as the Infinispan cache needs to be made
> available first).
>
> >
> > 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.
>
> I reopened HHH-12640, so we can delete WildFlyStandAloneJtaPlatform and
> have JBossStandAloneJtaPlatform look for any of the classes it can use.
> https://github.com/hibernate/hibernate-orm/pull/2317 is the PR for this
> change.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

On 05/29/2018 10:05 AM, Steve Ebersole wrote:
> On Tue, May 29, 2018 at 8:38 AM Scott Marlow  > 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?

I think we both agreed that for now, we should maintain the jipijapa 
code in WF, with a fork being kept in ORM, for testing and other 
purposes (like making a new ORM version available to already shipped WF 
versions).

I agree that we should sync our copies of this code, just not sure of 
how, other than discussing a comparison and picking which changes should 
be merged to the other copy.

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

Interesting, should RegionFactoryInitiator also support automatic 
"fallback" to the user configured region factory?  I assume not since we 
are enabling the second level cache on Hibernate ORM but currently are 
not able to do that in WildFly (as the Infinispan cache needs to be made 
available first).

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

I reopened HHH-12640, so we can delete WildFlyStandAloneJtaPlatform and 
have JBossStandAloneJtaPlatform look for any of the classes it can use. 
https://github.com/hibernate/hibernate-orm/pull/2317 is the PR for this 
change.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Steve Ebersole]

On Tue, May 29, 2018 at 8:38 AM Scott Marlow  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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

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

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.

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?

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

> 
> On Mon, May 28, 2018 at 12:31 PM Scott Marlow  > wrote:
> 
> A fix is merged to orm master branch, which should be in 5.3.2, as
> soon as that is available.
> 
> 
> On Sun, May 27, 2018, 7:06 PM Steve Ebersole  > wrote:
> 
> JBossStandalone is meant for use of JBoss Transactions outside
> of WildFly.  Why are we using it inside WildFly. 
> 
> 
> WildFly also supports non-jpa container managed deployments, that
> may not want to use the JtaPlatformInitiator.  These apps can opt
> out of the JtaPlatformInitiator but will need the correct TX status.
> 
> Inside WildFly, jipijapa ought to be defining that however it
> needs through a custom JtaPlatform and probably the
> JtaPlatformInitiator.
> 
> We do, by default.
> 
> 
> 
> On Sun, May 27, 2018, 3:58 PM Sanne Grinovero
> mailto:sa...@hibernate.org>> wrote:
> 
> On 27 May 2018 at 15:29, Scott Marlow  > wrote:
>  >
>  >
>  > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero
> mailto:sa...@hibernate.org>>
>  > wrote:
>  >>
>  >> On 27 May 2018 at 00:30, Scott Marlow
> mailto:smar...@redhat.com>> wrote:
>  >> > Next idea, we should first look for the WFTC classes,
> if not found, then
>  >> > look for Arjuna classes.
>  >>
>  >> +1 that would be nice and I see other implementations e.g.
>  >> JBossAppServerJtaPlatform have a precedent of attempting
> multiple
>  >> strategies to maintain backward compatibility.
>  >>
>  >> Created:
>  >>  - https://hibernate.atlassian.net/browse/HHH-12640
>  >
>  >
>  > https://github.com/hibernate/hibernate-orm/pull/2314
>  >
>  >>
>  >>
>  >>
>  >> Regarding the use of the old Arjuna name: you might be
> right that it
>  >> shouldn't be used, but it's still very common:
>  >>
>  >> even the Narayana quickstarts using Hibernate are broken
> by this
>  >> change, and so is any application running on WildFly
> Swarm or
>  >> Thorntail.
>  >>
>  >> I suppose something should be improved on their side as
> well, yet we
>  >> should give people time (by making it compatible like
> you suggested)
>  >> and help at least with some documented guidance - the
> fallback
>  >> strategy could log a warning to motivate people to
> update but IMO we
>  >> should start bugging people with such messages only when
> the other
>  >> runtimes and examples ship with the new defaults.
>  >>
>  >> Hibernate Search also has integration tests with
> Narayana (standalone
>  >> JTA) and it's not clear to me now which dependencies I
> should be
>  >> changing; I suppose I'll figure it out soon as I need to
> release it
>  >> too :)
>  >>
>  >> 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Steve Ebersole]

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.

On Mon, May 28, 2018 at 12:31 PM Scott Marlow  wrote:

> A fix is merged to orm master branch, which should be in 5.3.2, as soon as
> that is available.
>
>
> On Sun, May 27, 2018, 7:06 PM Steve Ebersole  wrote:
>
>> JBossStandalone is meant for use of JBoss Transactions outside of
>> WildFly.  Why are we using it inside WildFly.
>
>
> WildFly also supports non-jpa container managed deployments, that may not
> want to use the JtaPlatformInitiator.  These apps can opt out of the
> JtaPlatformInitiator but will need the correct TX status.
>
> Inside WildFly, jipijapa ought to be defining that however it needs
>> through a custom JtaPlatform and probably the JtaPlatformInitiator.
>>
> We do, by default.
>
>
>>
>> On Sun, May 27, 2018, 3:58 PM Sanne Grinovero 
>> wrote:
>>
>>> On 27 May 2018 at 15:29, Scott Marlow  wrote:
>>> >
>>> >
>>> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero 
>>> > wrote:
>>> >>
>>> >> On 27 May 2018 at 00:30, Scott Marlow  wrote:
>>> >> > Next idea, we should first look for the WFTC classes, if not found,
>>> then
>>> >> > look for Arjuna classes.
>>> >>
>>> >> +1 that would be nice and I see other implementations e.g.
>>> >> JBossAppServerJtaPlatform have a precedent of attempting multiple
>>> >> strategies to maintain backward compatibility.
>>> >>
>>> >> Created:
>>> >>  - https://hibernate.atlassian.net/browse/HHH-12640
>>> >
>>> >
>>> > https://github.com/hibernate/hibernate-orm/pull/2314
>>> >
>>> >>
>>> >>
>>> >>
>>> >> Regarding the use of the old Arjuna name: you might be right that it
>>> >> shouldn't be used, but it's still very common:
>>> >>
>>> >> even the Narayana quickstarts using Hibernate are broken by this
>>> >> change, and so is any application running on WildFly Swarm or
>>> >> Thorntail.
>>> >>
>>> >> I suppose something should be improved on their side as well, yet we
>>> >> should give people time (by making it compatible like you suggested)
>>> >> and help at least with some documented guidance - the fallback
>>> >> strategy could log a warning to motivate people to update but IMO we
>>> >> should start bugging people with such messages only when the other
>>> >> runtimes and examples ship with the new defaults.
>>> >>
>>> >> Hibernate Search also has integration tests with Narayana (standalone
>>> >> JTA) and it's not clear to me now which dependencies I should be
>>> >> changing; I suppose I'll figure it out soon as I need to release it
>>> >> too :)
>>> >>
>>> >> The user experience after this error is quite bad: applications now
>>> >> simply fail to start with a confusing
>>> >> "javax.persistence.PersistenceException: No Persistence provider for
>>> >> EntityManager named XYZ found", we give no better error and no clue
>>> >> about needing to look into the used transactions implementation.
>>> >>
>>> >> Created:
>>> >>  - https://hibernate.atlassian.net/browse/HHH-12639
>>> >>
>>> >> Thanks,
>>> >> Sanne
>>> >>
>>> >>
>>> >> >
>>> >> > On Sat, May 26, 2018, 7:12 PM Scott Marlow 
>>> wrote:
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow 
>>> wrote:
>>> >> >>>
>>> >> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>>> >> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup
>>> using the
>>> >> >>> standard JBoss TM/UT JNDI names.
>>> >> >>
>>> >> >>
>>> >> >> This wouldn't work for standard alone mode, as there wouldn't be
>>> any
>>> >> >> jndi
>>> >> >> services.  Guess, we are stuck with using class name references.
>>> >> >>
>>> >> >>>
>>> >> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow >> >
>>> >> >>> wrote:
>>> >> 
>>> >> 
>>> >>  On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>>> >>  
>>> >>  wrote:
>>> >> >
>>> >> > Hi Scott,
>>> >> >
>>> >> > I see you changed JBossStandAloneJtaPlatform to use a new API in
>>> >> > WildFly;
>>> >> 
>>> >> 
>>> >>  More that in WildFly 13, applications shouldn't use the Arjuna TM
>>> >>  classes directly anymore.  The WildFly Transaction Client wraps
>>> the
>>> >>  Arjuna
>>> >>  TM and maintains correct TX status.
>>> >> 
>>> >> >
>>> >> > this breaks all existing applications using a generic "JBoss -
>>> >> > standalone" platform which isn't using the very latest WildFly.
>>> >> 
>>> >> 
>>> >>  Hmm, thinking more about this, also broken, are any ORM 5.1.x
>>> >>  applications that depend on JBossStandAloneJtaPlatform to choose
>>> the
>>> >>  WildFly
>>> >>  TM.  JPA container managed applications won't have this problem.
>>> >> 
>>> >> >
>>> >> >
>>> >> > I see that in many cases this type is auto-detected - and while
>>> >> > JBossStandAloneJtaPlatform causes an exception this is
>>> swallowed 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

A fix is merged to orm master branch, which should be in 5.3.2, as soon as
that is available.

On Sun, May 27, 2018, 7:06 PM Steve Ebersole  wrote:

> JBossStandalone is meant for use of JBoss Transactions outside of
> WildFly.  Why are we using it inside WildFly.


WildFly also supports non-jpa container managed deployments, that may not
want to use the JtaPlatformInitiator.  These apps can opt out of the
JtaPlatformInitiator but will need the correct TX status.

Inside WildFly, jipijapa ought to be defining that however it needs through
> a custom JtaPlatform and probably the JtaPlatformInitiator.
>
We do, by default.


>
> On Sun, May 27, 2018, 3:58 PM Sanne Grinovero  wrote:
>
>> On 27 May 2018 at 15:29, Scott Marlow  wrote:
>> >
>> >
>> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero 
>> > wrote:
>> >>
>> >> On 27 May 2018 at 00:30, Scott Marlow  wrote:
>> >> > Next idea, we should first look for the WFTC classes, if not found,
>> then
>> >> > look for Arjuna classes.
>> >>
>> >> +1 that would be nice and I see other implementations e.g.
>> >> JBossAppServerJtaPlatform have a precedent of attempting multiple
>> >> strategies to maintain backward compatibility.
>> >>
>> >> Created:
>> >>  - https://hibernate.atlassian.net/browse/HHH-12640
>> >
>> >
>> > https://github.com/hibernate/hibernate-orm/pull/2314
>> >
>> >>
>> >>
>> >>
>> >> Regarding the use of the old Arjuna name: you might be right that it
>> >> shouldn't be used, but it's still very common:
>> >>
>> >> even the Narayana quickstarts using Hibernate are broken by this
>> >> change, and so is any application running on WildFly Swarm or
>> >> Thorntail.
>> >>
>> >> I suppose something should be improved on their side as well, yet we
>> >> should give people time (by making it compatible like you suggested)
>> >> and help at least with some documented guidance - the fallback
>> >> strategy could log a warning to motivate people to update but IMO we
>> >> should start bugging people with such messages only when the other
>> >> runtimes and examples ship with the new defaults.
>> >>
>> >> Hibernate Search also has integration tests with Narayana (standalone
>> >> JTA) and it's not clear to me now which dependencies I should be
>> >> changing; I suppose I'll figure it out soon as I need to release it
>> >> too :)
>> >>
>> >> The user experience after this error is quite bad: applications now
>> >> simply fail to start with a confusing
>> >> "javax.persistence.PersistenceException: No Persistence provider for
>> >> EntityManager named XYZ found", we give no better error and no clue
>> >> about needing to look into the used transactions implementation.
>> >>
>> >> Created:
>> >>  - https://hibernate.atlassian.net/browse/HHH-12639
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>
>> >> >
>> >> > On Sat, May 26, 2018, 7:12 PM Scott Marlow 
>> wrote:
>> >> >>
>> >> >>
>> >> >>
>> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow 
>> wrote:
>> >> >>>
>> >> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>> >> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using
>> the
>> >> >>> standard JBoss TM/UT JNDI names.
>> >> >>
>> >> >>
>> >> >> This wouldn't work for standard alone mode, as there wouldn't be any
>> >> >> jndi
>> >> >> services.  Guess, we are stuck with using class name references.
>> >> >>
>> >> >>>
>> >> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow 
>> >> >>> wrote:
>> >> 
>> >> 
>> >>  On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>> >>  
>> >>  wrote:
>> >> >
>> >> > Hi Scott,
>> >> >
>> >> > I see you changed JBossStandAloneJtaPlatform to use a new API in
>> >> > WildFly;
>> >> 
>> >> 
>> >>  More that in WildFly 13, applications shouldn't use the Arjuna TM
>> >>  classes directly anymore.  The WildFly Transaction Client wraps
>> the
>> >>  Arjuna
>> >>  TM and maintains correct TX status.
>> >> 
>> >> >
>> >> > this breaks all existing applications using a generic "JBoss -
>> >> > standalone" platform which isn't using the very latest WildFly.
>> >> 
>> >> 
>> >>  Hmm, thinking more about this, also broken, are any ORM 5.1.x
>> >>  applications that depend on JBossStandAloneJtaPlatform to choose
>> the
>> >>  WildFly
>> >>  TM.  JPA container managed applications won't have this problem.
>> >> 
>> >> >
>> >> >
>> >> > I see that in many cases this type is auto-detected - and while
>> >> > JBossStandAloneJtaPlatform causes an exception this is swallowed
>> by
>> >> > the HibernatePersistenceProvider as any exception is only
>> mentioned
>> >> > at
>> >> > debug level (line 61).
>> >
>> >
>> > This sounds correct, as all persistence providers are given a chance,
>> to try
>> > deploying a persistence provider when
>> > Persistence.createEntityManagerFactory() (or other calls, like
>> > generateSchema()) are made.
>>
>> I'm aware of how the selection is meant to work, but 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Steve Ebersole]

JBossStandalone is meant for use of JBoss Transactions outside of WildFly.
Why are we using it inside WildFly.  Inside WildFly, jipijapa ought to be
defining that however it needs through a custom JtaPlatform and probably
the JtaPlatformInitiator.


On Sun, May 27, 2018, 3:58 PM Sanne Grinovero  wrote:

> On 27 May 2018 at 15:29, Scott Marlow  wrote:
> >
> >
> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero 
> > wrote:
> >>
> >> On 27 May 2018 at 00:30, Scott Marlow  wrote:
> >> > Next idea, we should first look for the WFTC classes, if not found,
> then
> >> > look for Arjuna classes.
> >>
> >> +1 that would be nice and I see other implementations e.g.
> >> JBossAppServerJtaPlatform have a precedent of attempting multiple
> >> strategies to maintain backward compatibility.
> >>
> >> Created:
> >>  - https://hibernate.atlassian.net/browse/HHH-12640
> >
> >
> > https://github.com/hibernate/hibernate-orm/pull/2314
> >
> >>
> >>
> >>
> >> Regarding the use of the old Arjuna name: you might be right that it
> >> shouldn't be used, but it's still very common:
> >>
> >> even the Narayana quickstarts using Hibernate are broken by this
> >> change, and so is any application running on WildFly Swarm or
> >> Thorntail.
> >>
> >> I suppose something should be improved on their side as well, yet we
> >> should give people time (by making it compatible like you suggested)
> >> and help at least with some documented guidance - the fallback
> >> strategy could log a warning to motivate people to update but IMO we
> >> should start bugging people with such messages only when the other
> >> runtimes and examples ship with the new defaults.
> >>
> >> Hibernate Search also has integration tests with Narayana (standalone
> >> JTA) and it's not clear to me now which dependencies I should be
> >> changing; I suppose I'll figure it out soon as I need to release it
> >> too :)
> >>
> >> The user experience after this error is quite bad: applications now
> >> simply fail to start with a confusing
> >> "javax.persistence.PersistenceException: No Persistence provider for
> >> EntityManager named XYZ found", we give no better error and no clue
> >> about needing to look into the used transactions implementation.
> >>
> >> Created:
> >>  - https://hibernate.atlassian.net/browse/HHH-12639
> >>
> >> Thanks,
> >> Sanne
> >>
> >>
> >> >
> >> > On Sat, May 26, 2018, 7:12 PM Scott Marlow 
> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow 
> wrote:
> >> >>>
> >> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
> >> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using
> the
> >> >>> standard JBoss TM/UT JNDI names.
> >> >>
> >> >>
> >> >> This wouldn't work for standard alone mode, as there wouldn't be any
> >> >> jndi
> >> >> services.  Guess, we are stuck with using class name references.
> >> >>
> >> >>>
> >> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow 
> >> >>> wrote:
> >> 
> >> 
> >>  On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
> >>  
> >>  wrote:
> >> >
> >> > Hi Scott,
> >> >
> >> > I see you changed JBossStandAloneJtaPlatform to use a new API in
> >> > WildFly;
> >> 
> >> 
> >>  More that in WildFly 13, applications shouldn't use the Arjuna TM
> >>  classes directly anymore.  The WildFly Transaction Client wraps the
> >>  Arjuna
> >>  TM and maintains correct TX status.
> >> 
> >> >
> >> > this breaks all existing applications using a generic "JBoss -
> >> > standalone" platform which isn't using the very latest WildFly.
> >> 
> >> 
> >>  Hmm, thinking more about this, also broken, are any ORM 5.1.x
> >>  applications that depend on JBossStandAloneJtaPlatform to choose
> the
> >>  WildFly
> >>  TM.  JPA container managed applications won't have this problem.
> >> 
> >> >
> >> >
> >> > I see that in many cases this type is auto-detected - and while
> >> > JBossStandAloneJtaPlatform causes an exception this is swallowed
> by
> >> > the HibernatePersistenceProvider as any exception is only
> mentioned
> >> > at
> >> > debug level (line 61).
> >
> >
> > This sounds correct, as all persistence providers are given a chance, to
> try
> > deploying a persistence provider when
> > Persistence.createEntityManagerFactory() (or other calls, like
> > generateSchema()) are made.
>
> I'm aware of how the selection is meant to work, but shouldn't we be
> able to differentiate between the typical scenario "this configuration
> is not meant for me" vs the scenario of an unintended failure because
> of an internal exception?
>
> Especially as in this case you claim it's the user's fault that an
> exception happens, as the user is having an out of date, incompatible
> library on the 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Sanne Grinovero]

On 27 May 2018 at 15:29, Scott Marlow  wrote:
>
>
> On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero 
> wrote:
>>
>> On 27 May 2018 at 00:30, Scott Marlow  wrote:
>> > Next idea, we should first look for the WFTC classes, if not found, then
>> > look for Arjuna classes.
>>
>> +1 that would be nice and I see other implementations e.g.
>> JBossAppServerJtaPlatform have a precedent of attempting multiple
>> strategies to maintain backward compatibility.
>>
>> Created:
>>  - https://hibernate.atlassian.net/browse/HHH-12640
>
>
> https://github.com/hibernate/hibernate-orm/pull/2314
>
>>
>>
>>
>> Regarding the use of the old Arjuna name: you might be right that it
>> shouldn't be used, but it's still very common:
>>
>> even the Narayana quickstarts using Hibernate are broken by this
>> change, and so is any application running on WildFly Swarm or
>> Thorntail.
>>
>> I suppose something should be improved on their side as well, yet we
>> should give people time (by making it compatible like you suggested)
>> and help at least with some documented guidance - the fallback
>> strategy could log a warning to motivate people to update but IMO we
>> should start bugging people with such messages only when the other
>> runtimes and examples ship with the new defaults.
>>
>> Hibernate Search also has integration tests with Narayana (standalone
>> JTA) and it's not clear to me now which dependencies I should be
>> changing; I suppose I'll figure it out soon as I need to release it
>> too :)
>>
>> The user experience after this error is quite bad: applications now
>> simply fail to start with a confusing
>> "javax.persistence.PersistenceException: No Persistence provider for
>> EntityManager named XYZ found", we give no better error and no clue
>> about needing to look into the used transactions implementation.
>>
>> Created:
>>  - https://hibernate.atlassian.net/browse/HHH-12639
>>
>> Thanks,
>> Sanne
>>
>>
>> >
>> > On Sat, May 26, 2018, 7:12 PM Scott Marlow  wrote:
>> >>
>> >>
>> >>
>> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow  wrote:
>> >>>
>> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
>> >>> standard JBoss TM/UT JNDI names.
>> >>
>> >>
>> >> This wouldn't work for standard alone mode, as there wouldn't be any
>> >> jndi
>> >> services.  Guess, we are stuck with using class name references.
>> >>
>> >>>
>> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow 
>> >>> wrote:
>> 
>> 
>>  On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
>>  
>>  wrote:
>> >
>> > Hi Scott,
>> >
>> > I see you changed JBossStandAloneJtaPlatform to use a new API in
>> > WildFly;
>> 
>> 
>>  More that in WildFly 13, applications shouldn't use the Arjuna TM
>>  classes directly anymore.  The WildFly Transaction Client wraps the
>>  Arjuna
>>  TM and maintains correct TX status.
>> 
>> >
>> > this breaks all existing applications using a generic "JBoss -
>> > standalone" platform which isn't using the very latest WildFly.
>> 
>> 
>>  Hmm, thinking more about this, also broken, are any ORM 5.1.x
>>  applications that depend on JBossStandAloneJtaPlatform to choose the
>>  WildFly
>>  TM.  JPA container managed applications won't have this problem.
>> 
>> >
>> >
>> > I see that in many cases this type is auto-detected - and while
>> > JBossStandAloneJtaPlatform causes an exception this is swallowed by
>> > the HibernatePersistenceProvider as any exception is only mentioned
>> > at
>> > debug level (line 61).
>
>
> This sounds correct, as all persistence providers are given a chance, to try
> deploying a persistence provider when
> Persistence.createEntityManagerFactory() (or other calls, like
> generateSchema()) are made.

I'm aware of how the selection is meant to work, but shouldn't we be
able to differentiate between the typical scenario "this configuration
is not meant for me" vs the scenario of an unintended failure because
of an internal exception?

Especially as in this case you claim it's the user's fault that an
exception happens, as the user is having an out of date, incompatible
library on the classpath. Clearly, we shouldn't swallow the error as
it makes it massively difficult to suggest some upgrades need to be
explored.

IMO it would be very reasonable to change the exception log from debug
to warn/error but indeed I'm asking here as I understand the TCK /
spec intent might disagree with this. I doubt the TCK tests for
absence of error messaged being logged though?

Thanks,
Sanne



>
>>
>> >
>> > So two questions:
>> >  - could this be reverted and you introduce some new-gen
>> > WildflyStandAloneJtaPlatform instead?
>
>
> Yes, good idea 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero 
wrote:

> On 27 May 2018 at 00:30, Scott Marlow  wrote:
> > Next idea, we should first look for the WFTC classes, if not found, then
> > look for Arjuna classes.
>
> +1 that would be nice and I see other implementations e.g.
> JBossAppServerJtaPlatform have a precedent of attempting multiple
> strategies to maintain backward compatibility.
>
> Created:
>  - https://hibernate.atlassian.net/browse/HHH-12640


https://github.com/hibernate/hibernate-orm/pull/2314


>
>
> Regarding the use of the old Arjuna name: you might be right that it
> shouldn't be used, but it's still very common:
>
> even the Narayana quickstarts using Hibernate are broken by this
> change, and so is any application running on WildFly Swarm or
> Thorntail.
>
> I suppose something should be improved on their side as well, yet we
> should give people time (by making it compatible like you suggested)
> and help at least with some documented guidance - the fallback
> strategy could log a warning to motivate people to update but IMO we
> should start bugging people with such messages only when the other
> runtimes and examples ship with the new defaults.
>
> Hibernate Search also has integration tests with Narayana (standalone
> JTA) and it's not clear to me now which dependencies I should be
> changing; I suppose I'll figure it out soon as I need to release it
> too :)
>
> The user experience after this error is quite bad: applications now
> simply fail to start with a confusing
> "javax.persistence.PersistenceException: No Persistence provider for
> EntityManager named XYZ found", we give no better error and no clue
> about needing to look into the used transactions implementation.
>
> Created:
>  - https://hibernate.atlassian.net/browse/HHH-12639
>
> Thanks,
> Sanne
>
>
> >
> > On Sat, May 26, 2018, 7:12 PM Scott Marlow  wrote:
> >>
> >>
> >>
> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow  wrote:
> >>>
> >>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
> >>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
> >>> standard JBoss TM/UT JNDI names.
> >>
> >>
> >> This wouldn't work for standard alone mode, as there wouldn't be any
> jndi
> >> services.  Guess, we are stuck with using class name references.
> >>
> >>>
> >>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow 
> wrote:
> 
> 
>  On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero  >
>  wrote:
> >
> > Hi Scott,
> >
> > I see you changed JBossStandAloneJtaPlatform to use a new API in
> > WildFly;
> 
> 
>  More that in WildFly 13, applications shouldn't use the Arjuna TM
>  classes directly anymore.  The WildFly Transaction Client wraps the
> Arjuna
>  TM and maintains correct TX status.
> 
> >
> > this breaks all existing applications using a generic "JBoss -
> > standalone" platform which isn't using the very latest WildFly.
> 
> 
>  Hmm, thinking more about this, also broken, are any ORM 5.1.x
>  applications that depend on JBossStandAloneJtaPlatform to choose the
> WildFly
>  TM.  JPA container managed applications won't have this problem.
> 
> >
> >
> > I see that in many cases this type is auto-detected - and while
> > JBossStandAloneJtaPlatform causes an exception this is swallowed by
> > the HibernatePersistenceProvider as any exception is only mentioned
> at
> > debug level (line 61).
>

This sounds correct, as all persistence providers are given a chance, to
try deploying a persistence provider when
Persistence.createEntityManagerFactory() (or other calls, like
generateSchema()) are made.


> >
> > So two questions:
> >  - could this be reverted and you introduce some new-gen
> > WildflyStandAloneJtaPlatform instead?
>

Yes, good idea https://github.com/hibernate/hibernate-orm/pull/2314


> 
>  Not sure, since the WildFly Transaction Client (WFTC) module is also
> in
>  earlier WF releases.  I'm not exactly sure of when the WFTC TM
> replaces
>  Arjuna TM.  David, is that new for WF13?
> 
>  We can get more correct in ORM 5.3.x to align with WF 13, but not sure
>  about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
>  directly.  Seems like that is also a problem.
> 
> >
> >  - bootstrap exceptions: may I change those to error level?
> 
> 
>  No idea.
> 
> >
> >
> > Thanks,
> > Sanne
> 
> 
> >>>
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Sanne Grinovero]

On 27 May 2018 at 00:30, Scott Marlow  wrote:
> Next idea, we should first look for the WFTC classes, if not found, then
> look for Arjuna classes.

+1 that would be nice and I see other implementations e.g.
JBossAppServerJtaPlatform have a precedent of attempting multiple
strategies to maintain backward compatibility.

Created:
 - https://hibernate.atlassian.net/browse/HHH-12640

Regarding the use of the old Arjuna name: you might be right that it
shouldn't be used, but it's still very common:

even the Narayana quickstarts using Hibernate are broken by this
change, and so is any application running on WildFly Swarm or
Thorntail.

I suppose something should be improved on their side as well, yet we
should give people time (by making it compatible like you suggested)
and help at least with some documented guidance - the fallback
strategy could log a warning to motivate people to update but IMO we
should start bugging people with such messages only when the other
runtimes and examples ship with the new defaults.

Hibernate Search also has integration tests with Narayana (standalone
JTA) and it's not clear to me now which dependencies I should be
changing; I suppose I'll figure it out soon as I need to release it
too :)

The user experience after this error is quite bad: applications now
simply fail to start with a confusing
"javax.persistence.PersistenceException: No Persistence provider for
EntityManager named XYZ found", we give no better error and no clue
about needing to look into the used transactions implementation.

Created:
 - https://hibernate.atlassian.net/browse/HHH-12639

Thanks,
Sanne


>
> On Sat, May 26, 2018, 7:12 PM Scott Marlow  wrote:
>>
>>
>>
>> On Sat, May 26, 2018, 6:05 PM Scott Marlow  wrote:
>>>
>>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME +
>>> JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
>>> standard JBoss TM/UT JNDI names.
>>
>>
>> This wouldn't work for standard alone mode, as there wouldn't be any jndi
>> services.  Guess, we are stuck with using class name references.
>>
>>>
>>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow  wrote:


 On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 
 wrote:
>
> Hi Scott,
>
> I see you changed JBossStandAloneJtaPlatform to use a new API in
> WildFly;


 More that in WildFly 13, applications shouldn't use the Arjuna TM
 classes directly anymore.  The WildFly Transaction Client wraps the Arjuna
 TM and maintains correct TX status.

>
> this breaks all existing applications using a generic "JBoss -
> standalone" platform which isn't using the very latest WildFly.


 Hmm, thinking more about this, also broken, are any ORM 5.1.x
 applications that depend on JBossStandAloneJtaPlatform to choose the 
 WildFly
 TM.  JPA container managed applications won't have this problem.

>
>
> I see that in many cases this type is auto-detected - and while
> JBossStandAloneJtaPlatform causes an exception this is swallowed by
> the HibernatePersistenceProvider as any exception is only mentioned at
> debug level (line 61).
>
> So two questions:
>  - could this be reverted and you introduce some new-gen
> WildflyStandAloneJtaPlatform instead?


 Not sure, since the WildFly Transaction Client (WFTC) module is also in
 earlier WF releases.  I'm not exactly sure of when the WFTC TM replaces
 Arjuna TM.  David, is that new for WF13?

 We can get more correct in ORM 5.3.x to align with WF 13, but not sure
 about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
 directly.  Seems like that is also a problem.

>
>  - bootstrap exceptions: may I change those to error level?


 No idea.

>
>
> Thanks,
> Sanne


>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

Next idea, we should first look for the WFTC classes, if not found, then
look for Arjuna classes.

On Sat, May 26, 2018, 7:12 PM Scott Marlow  wrote:

>
>
> On Sat, May 26, 2018, 6:05 PM Scott Marlow  wrote:
>
>> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME
>> + JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
>> standard JBoss TM/UT JNDI names.
>>
>
> This wouldn't work for standard alone mode, as there wouldn't be any jndi
> services.  Guess, we are stuck with using class name references.
>
>
>> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow  wrote:
>>
>>>
>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 
>>> wrote:
>>>
 Hi Scott,

 I see you changed JBossStandAloneJtaPlatform to use a new API in
 WildFly;

>>>
>>> More that in WildFly 13, applications shouldn't use the Arjuna TM
>>> classes directly anymore.  The WildFly Transaction Client wraps the Arjuna
>>> TM and maintains correct TX status.
>>>
>>>
 this breaks all existing applications using a generic "JBoss -
 standalone" platform which isn't using the very latest WildFly.

>>>
>>> Hmm, thinking more about this, also broken, are any ORM 5.1.x
>>> applications that depend on JBossStandAloneJtaPlatform to choose the
>>> WildFly TM.  JPA container managed applications won't have this problem.
>>>
>>>

 I see that in many cases this type is auto-detected - and while
 JBossStandAloneJtaPlatform causes an exception this is swallowed by
 the HibernatePersistenceProvider as any exception is only mentioned at
 debug level (line 61).

 So two questions:
  - could this be reverted and you introduce some new-gen
 WildflyStandAloneJtaPlatform instead?

>>>
>>> Not sure, since the WildFly Transaction Client (WFTC) module is also in
>>> earlier WF releases.  I'm not exactly sure of when the WFTC TM replaces
>>> Arjuna TM.  David, is that new for WF13?
>>>
>>> We can get more correct in ORM 5.3.x to align with WF 13, but not sure
>>> about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
>>> directly.  Seems like that is also a problem.
>>>
>>>
  - bootstrap exceptions: may I change those to error level?

>>>
>>> No idea.
>>>
>>>

 Thanks,
 Sanne

>>>
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

On Sat, May 26, 2018, 6:05 PM Scott Marlow  wrote:

> Or, maybe we should just remove the JBOSS_TM_CLASS_NAME
> + JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
> standard JBoss TM/UT JNDI names.
>

This wouldn't work for standard alone mode, as there wouldn't be any jndi
services.  Guess, we are stuck with using class name references.


> On Sat, May 26, 2018 at 5:05 PM, Scott Marlow  wrote:
>
>>
>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 
>> wrote:
>>
>>> Hi Scott,
>>>
>>> I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;
>>>
>>
>> More that in WildFly 13, applications shouldn't use the Arjuna TM classes
>> directly anymore.  The WildFly Transaction Client wraps the Arjuna TM and
>> maintains correct TX status.
>>
>>
>>> this breaks all existing applications using a generic "JBoss -
>>> standalone" platform which isn't using the very latest WildFly.
>>>
>>
>> Hmm, thinking more about this, also broken, are any ORM 5.1.x
>> applications that depend on JBossStandAloneJtaPlatform to choose the
>> WildFly TM.  JPA container managed applications won't have this problem.
>>
>>
>>>
>>> I see that in many cases this type is auto-detected - and while
>>> JBossStandAloneJtaPlatform causes an exception this is swallowed by
>>> the HibernatePersistenceProvider as any exception is only mentioned at
>>> debug level (line 61).
>>>
>>> So two questions:
>>>  - could this be reverted and you introduce some new-gen
>>> WildflyStandAloneJtaPlatform instead?
>>>
>>
>> Not sure, since the WildFly Transaction Client (WFTC) module is also in
>> earlier WF releases.  I'm not exactly sure of when the WFTC TM replaces
>> Arjuna TM.  David, is that new for WF13?
>>
>> We can get more correct in ORM 5.3.x to align with WF 13, but not sure
>> about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
>> directly.  Seems like that is also a problem.
>>
>>
>>>  - bootstrap exceptions: may I change those to error level?
>>>
>>
>> No idea.
>>
>>
>>>
>>> Thanks,
>>> Sanne
>>>
>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

Or, maybe we should just remove the JBOSS_TM_CLASS_NAME
+ JBOSS_UT_CLASS_NAME class references and instead JNDI lookup using the
standard JBoss TM/UT JNDI names.

On Sat, May 26, 2018 at 5:05 PM, Scott Marlow  wrote:

>
> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 
> wrote:
>
>> Hi Scott,
>>
>> I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;
>>
>
> More that in WildFly 13, applications shouldn't use the Arjuna TM classes
> directly anymore.  The WildFly Transaction Client wraps the Arjuna TM and
> maintains correct TX status.
>
>
>> this breaks all existing applications using a generic "JBoss -
>> standalone" platform which isn't using the very latest WildFly.
>>
>
> Hmm, thinking more about this, also broken, are any ORM 5.1.x applications
> that depend on JBossStandAloneJtaPlatform to choose the WildFly TM.  JPA
> container managed applications won't have this problem.
>
>
>>
>> I see that in many cases this type is auto-detected - and while
>> JBossStandAloneJtaPlatform causes an exception this is swallowed by
>> the HibernatePersistenceProvider as any exception is only mentioned at
>> debug level (line 61).
>>
>> So two questions:
>>  - could this be reverted and you introduce some new-gen
>> WildflyStandAloneJtaPlatform instead?
>>
>
> Not sure, since the WildFly Transaction Client (WFTC) module is also in
> earlier WF releases.  I'm not exactly sure of when the WFTC TM replaces
> Arjuna TM.  David, is that new for WF13?
>
> We can get more correct in ORM 5.3.x to align with WF 13, but not sure
> about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
> directly.  Seems like that is also a problem.
>
>
>>  - bootstrap exceptions: may I change those to error level?
>>
>
> No idea.
>
>
>>
>> Thanks,
>> Sanne
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Scott Marlow]

On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 
wrote:

> Hi Scott,
>
> I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly;
>

More that in WildFly 13, applications shouldn't use the Arjuna TM classes
directly anymore.  The WildFly Transaction Client wraps the Arjuna TM and
maintains correct TX status.


> this breaks all existing applications using a generic "JBoss -
> standalone" platform which isn't using the very latest WildFly.
>

Hmm, thinking more about this, also broken, are any ORM 5.1.x applications
that depend on JBossStandAloneJtaPlatform to choose the WildFly TM.  JPA
container managed applications won't have this problem.


>
> I see that in many cases this type is auto-detected - and while
> JBossStandAloneJtaPlatform causes an exception this is swallowed by
> the HibernatePersistenceProvider as any exception is only mentioned at
> debug level (line 61).
>
> So two questions:
>  - could this be reverted and you introduce some new-gen
> WildflyStandAloneJtaPlatform instead?
>

Not sure, since the WildFly Transaction Client (WFTC) module is also in
earlier WF releases.  I'm not exactly sure of when the WFTC TM replaces
Arjuna TM.  David, is that new for WF13?

We can get more correct in ORM 5.3.x to align with WF 13, but not sure
about ORM 5.1 JBossStandAloneJtaPlatform still referencing Arjuna TM
directly.  Seems like that is also a problem.


>  - bootstrap exceptions: may I change those to error level?
>

No idea.


>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev