[hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Mon May 28 07:23:57 EDT 2018

On 28 May 2018 at 00:05, 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.  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.

Thanks,
Sanne

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