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(a)hibernate.org> wrote:
>
> On 27 May 2018 at 15:29, Scott Marlow <smarlow(a)redhat.com> wrote:
> >
> >
> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero <sanne(a)hibernate.org>
> > wrote:
> >>
> >> On 27 May 2018 at 00:30, Scott Marlow <smarlow(a)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(a)redhat.com>
> >> > wrote:
> >> >>
> >> >>
> >> >>
> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow
<smarlow(a)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(a)redhat.com>
> >> >>> wrote:
> >> >>>>
> >> >>>>
> >> >>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero
> >> >>>> <sanne(a)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(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev