On 28 May 2018 at 00:05, Steve Ebersole <st...@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 <sa...@hibernate.org> wrote: >> >> On 27 May 2018 at 15:29, Scott Marlow <smar...@redhat.com> wrote: >> > >> > >> > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero <sa...@hibernate.org> >> > wrote: >> >> >> >> On 27 May 2018 at 00:30, Scott Marlow <smar...@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 <smar...@redhat.com> >> >> > wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Sat, May 26, 2018, 6:05 PM Scott Marlow <smar...@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 <smar...@redhat.com> >> >> >>> wrote: >> >> >>>> >> >> >>>> >> >> >>>> On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero >> >> >>>> <sa...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
