]
Tom Jenkinson commented on JBTM-2357:
-------------------------------------
To clarify the difficulty, Arjuna calculates the name of the file based on the manifest,
then a default name. It then goes through another algorithm trying to locate the file in a
number of locations. Adding a new location to check would be trivial but having two
default names would be tricky. We would provide the system property for now.
I should also clarify that the reason we can't change the name isn't just
backwards compatability. The name of the standalone project is narayana (formally JBossTS
and previously Arjuna). But the name of the actual component where this code resides is
really Arjuna - hence the default name.
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: Enhancement
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.