[hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

[Sanne Grinovero]

On 27 May 2018 at 00:30, Scott Marlow <smarlow at 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

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 <smarlow at redhat.com> wrote:
>>
>>
>>
>> On Sat, May 26, 2018, 6:05 PM Scott Marlow <smarlow at redhat.com> 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 <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
>>>>
>>>>
>>>
>