[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 <smarlow at redhat.com> wrote:

>
> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero <sanne at hibernate.org>
> 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
>>
>
>