Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 4 June 2018 at 12:23, Tom Jenkinson wrote: > > > On 28 May 2018 at 12:23, Sanne Grinovero wrote: >> >> On 28 May 2018 at 00:05, Steve Ebersole wrote: >> > JBossStandalone is meant for use of JBoss Transactions outside of >> > WildFly. >> > Why are we using it inside WildFly. Inside WildFly,

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

The implementation from hibernate-jipijapa returns disabling caching at all if the user did not specify any value. That was what you wanted to happen per our discussion at that time. Really I can make it do whatever you want - just not sure of a better answer. Also the point of a "fallback" is

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 05/29/2018 10:05 AM, Steve Ebersole wrote: > On Tue, May 29, 2018 at 8:38 AM Scott Marlow > wrote: > > > On 05/29/2018 08:48 AM, Steve Ebersole wrote: > > By "non-jpa container managed deployments" you mean injecting > Hibernate > > Sessions? 

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Tue, May 29, 2018 at 8:38 AM Scott Marlow wrote: > > On 05/29/2018 08:48 AM, Steve Ebersole wrote: > > 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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 05/29/2018 08:48 AM, Steve Ebersole wrote: > 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. Applications that

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

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 wrote: > A fix is merged to

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

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 wrote: > JBossStandalone is meant for use of JBoss Transactions outside of > WildFly. Why are we using it inside WildFly. WildFly also supports non-jpa

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 27 May 2018 at 15:29, Scott Marlow wrote: > > > On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero > wrote: >> >> On 27 May 2018 at 00:30, Scott Marlow wrote: >> > Next idea, we should first look for the WFTC classes, if not found,

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sun, May 27, 2018 at 8:17 AM, Sanne Grinovero wrote: > On 27 May 2018 at 00:30, Scott Marlow 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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On 27 May 2018 at 00:30, Scott Marlow 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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Next idea, we should first look for the WFTC classes, if not found, then look for Arjuna classes. On Sat, May 26, 2018, 7:12 PM Scott Marlow wrote: > > > On Sat, May 26, 2018, 6:05 PM Scott Marlow wrote: > >> Or, maybe we should just remove the

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sat, May 26, 2018, 6:05 PM Scott Marlow 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

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

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 wrote: > > On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero

Re: [hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

On Sat, May 26, 2018 at 9:04 AM, Sanne Grinovero 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

[hibernate-dev] Breaking JBossStandAloneJtaPlatform backwards compatibility

Hi Scott, I see you changed JBossStandAloneJtaPlatform to use a new API in WildFly; this breaks all existing applications using a generic "JBoss - standalone" platform which isn't using the very latest WildFly. I see that in many cases this type is auto-detected - and while