[hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Tue May 29 08:48:30 EDT 2018

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