]
Tom Jenkinson commented on JBTM-2357:
-------------------------------------
Hi Toby, we can't change it to look for jbossts-properties.xml solely, the reason we
can't remove the check for arjuna-properties.xml is due to backwards compatibility.
The work in JBTM-482 was about changing the file name inside JBoss really which was
completed. As such, I see this as an enhancement.
Would allowing a system property to override the default name of the file work for you?
jbossts-properties.xml not loaded if arjuna-properties-file not set
in manifest
-------------------------------------------------------------------------------
Key: JBTM-2357
URL:
https://issues.jboss.org/browse/JBTM-2357
Project: JBoss Transaction Manager
Issue Type: Bug
Affects Versions: 5.0.3
Reporter: Toby Crawley
Assignee: Tom Jenkinson
If the property isn't set, ConfigurationInfo falls back to looking for
"arjuna-properties.xml" because of
https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna....
Is that default intentional, or should it have been set to
"jbossts-properties.xml" as part of JBTM-482?
We're running in to this with [
Immutant|http://immutant.org], where the user can run
their application as a set of jars or as an uberjar. When ran as a set of jars, the
manifest from narayana-jta.jar has arjuna-properties-file set, and the jar provides a
jbossts-properties.xml at the top level that gets loaded. But when the user creates an
uberjar (a process we don't control), the uberjar includes the jbossts-properties.xml
file from the jta jar, but does not include the arjuna-properties-file property in the
manifest, which causes narayana to fail because the node id isn't set. We'd prefer
the same behavior in either run mode, so currently provide an arjuna-properties.xml that
is identical to the default from the jta jar to work around the issue.