[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson resolved JBTM-2357.
---------------------------------
Resolution: Rejected
I will reject this issue because it is possible to set the file name to look for via system property or via manifest entry. The default property file name can't be changed because it is in a library used by Narayana and potentially other products. If the system property approach doesn't work for you, please can you open a discussion on our forum and we can chat about the best way to do this for you: https://developer.jboss.org/en/jbosstm/
Thanks again for the report,
Tom
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2357:
-------------------------------------
Oops, I should have checked - that property already exists - sorry!
Its com.arjuna.ats.arjuna.common.propertiesFile
So you just need to call -Dcom.arjuna.ats.arjuna.common.propertiesFile=arjuna-properties.xml
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on JBTM-2357:
-------------------------------------
To further expand. Arjuna is a library in this case and not necessarily only used by JBTM/Narayana so those components can't impose their name on it.
I think either a system property, or a more invasive change such that when Narayana/JBTM is activated it first initializes the default name of the file. I would prefer a system property check here:
https://github.com/jbosstm/narayana/blob/master/common/classes/com/arjuna...
private static String propertiesFile = System.getProperty("arjuna-properties-xml-name", "arjuna-properties.xml");
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Michael Musgrove commented on JBTM-2357:
----------------------------------------
Maybe we could support both default file names - ie we look for both before failing.
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated JBTM-2357:
--------------------------------
Issue Type: Enhancement (was: Bug)
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2357) jbossts-properties.xml not loaded if arjuna-properties-file not set in manifest
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/JBTM-2357?page=com.atlassian.jira.plugin.... ]
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.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years
[JBoss JIRA] (JBTM-2101) Blacktie integration CSTest hang
by Amos Feng (JIRA)
[ https://issues.jboss.org/browse/JBTM-2101?page=com.atlassian.jira.plugin.... ]
Amos Feng edited comment on JBTM-2101 at 4/9/15 2:58 AM:
---------------------------------------------------------
The test setup is failed with starting the server with error "cannot start the same id server". It's caused by the .testsui queue not being undeployed on the server. So it looks like the prev test tearDown does not wait for the server shutdow finishing.
from the integration tests codes blacktie/integration-tests/src/test/java/org/jboss/narayana/blacktie/jatmibroker/xatmi/CSControl.java
{code}
public void tearDown() {
log.info("tearDown");
try {
if (server != null) {
log.debug("destroying server process");
server.interrupt();
server.getProcess().destroy();
log.debug("destroyed server process");
server.getProcess().waitFor();
}
log.debug("waited for server process");
} catch (Throwable e) {
throw new RuntimeException("Server shutdown error: ", e);
}
}
{code}
It looks like it does not need to destroy the process and just wait for it exits.
was (Author: zhfeng):
The test setup is failed with starting the server with error "cannot start the same id server". It's caused by the .testsui queue not being deployed on the server. So it looks like the prev test tearDown does not wait for the server shutdow finishing.
from the integration tests codes blacktie/integration-tests/src/test/java/org/jboss/narayana/blacktie/jatmibroker/xatmi/CSControl.java
{code}
public void tearDown() {
log.info("tearDown");
try {
if (server != null) {
log.debug("destroying server process");
server.interrupt();
server.getProcess().destroy();
log.debug("destroyed server process");
server.getProcess().waitFor();
}
log.debug("waited for server process");
} catch (Throwable e) {
throw new RuntimeException("Server shutdown error: ", e);
}
}
{code}
It looks like it does not need to destroy the process and just wait for it exits.
> Blacktie integration CSTest hang
> --------------------------------
>
> Key: JBTM-2101
> URL: https://issues.jboss.org/browse/JBTM-2101
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: BlackTie
> Reporter: Gytis Trikleris
> Assignee: Amos Feng
> Priority: Minor
> Fix For: 5.0.5
>
>
> http://172.17.131.2/view/Narayana+BlackTie/job/narayana/427/PROFILE=BLACK...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years