[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 <steve at hibernate.org> 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 <sanne at hibernate.org> wrote:
>
>> On 27 May 2018 at 15:29, Scott Marlow <smarlow at redhat.com> wrote:
>> >
>> >
>> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero <sanne at hibernate.org>
>> > wrote:
>> >>
>> >> 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
>> >
>> >
>> > 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 <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).
>> >
>> >
>> > 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 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>