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.
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). >> >> So two questions: >> - could this be reverted and you introduce some new-gen >> WildflyStandAloneJtaPlatform instead? >> > > 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
