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 JBOSS_TM_CLASS_NAME
>> + JBOSS_UT_CLASS_NAME class
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 wouldn't be any jndi
se
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
> wrote:
>
>> Hi Scott,
>>
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 wraps the Arjuna TM and
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
JBossStandAloneJtaPla
