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 <smar...@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 <st...@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 <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