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