January 2018 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps

by Michal Karm Babacek (JIRA)

[ https://issues.jboss.org/browse/JBTM-2986?page=com.atlassian.jira.plugin.... ] Michal Karm Babacek updated JBTM-2986: -------------------------------------- Attachment: maven.log.zip > Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps > ------------------------------------------------------------------------------------------------------------ > > Key: JBTM-2986 > URL: https://issues.jboss.org/browse/JBTM-2986 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.2.Final > Environment: IBM JDK 8 > Reporter: Michal Karm Babacek > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > Attachments: maven.log.zip > > > I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. > See [^maven.log.zip]. > h3. Excerpt > {noformat} > [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) > on project lra-test: An Ant BuildException has occured: Execute failed: > java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" > (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): > error=2, No such file or directory > [ERROR] around Ant part ...<exec executable="/qa/tools/opt/x86_64/ibm-java-80/bin/jps">... > @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml > {noformat} > I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. > WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2986) Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps

by Michal Karm Babacek (JIRA)

Michal Karm Babacek created JBTM-2986: ----------------------------------------- Summary: Cannot build LRA on IBM JDK 8:lra-test: An Ant BuildException has occurred, looking for non-existing bin/jps Key: JBTM-2986 URL: https://issues.jboss.org/browse/JBTM-2986 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.7.2.Final Environment: IBM JDK 8 Reporter: Michal Karm Babacek Assignee: Ondra Chaloupka Fix For: 5.7.2.Final I would like to build and test Narayana on IBM JDK and it seems the LRA test module is looking for {{jps}} that doesn't exist on IBM JDK. There should be some profile/wrapper to skip or port this part so as it works on IBM JDK without an explicit path to bin/jps. See [^maven.log.zip]. h3. Excerpt {noformat} [ERROR] Failed to execute goal org.apache.maven.plugins:maven-antrun-plugin:1.8:run (stop) on project lra-test: An Ant BuildException has occured: Execute failed: java.io.IOException: Cannot run program "/qa/tools/opt/x86_64/ibm-java-80/bin/jps" (in directory "/opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test"): error=2, No such file or directory [ERROR] around Ant part ...<exec executable="/qa/tools/opt/x86_64/ibm-java-80/bin/jps">... @ 4:63 in /opt/workspace/workspace/jws5-narayana-smoke-linux/cb703450/rts/lra/lra-test/target/antrun/build-main.xml {noformat} I tried to "workaround" it temporarily with {{-DskipTests -Dmaven.test.skip=true}}; no luck. WDYT? -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2950: -------------------------------- Fix Version/s: 5.7.2.Final > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2950) LRA logging is wrong in pointing to tsLogger and using System.out

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2950?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2950. ------------------------------- > LRA logging is wrong in pointing to tsLogger and using System.out > ----------------------------------------------------------------- > > Key: JBTM-2950 > URL: https://issues.jboss.org/browse/JBTM-2950 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > The LRA module uses inconsistent way of logging. Some parts uses the {{com.arjuna.ats.arjuna.logging}} which is wrong as it should define its own logger category to use in LRA. Other ones uses {{System.out|err}} for printing log information. > Up to that there should be more consistency and more informative for user. > * There are hidden reasons of some failures in some places. > * The error messages get from the URL queries are unclear in some cases, e.g. > {{not present: null: Cannont connect to an LRA coordinator: Connection refused}} > (what does means {{not present}} and why {{null}}? this is a bit misguiding info which is not necessary to be part of the error message) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2952: -------------------------------- Fix Version/s: 5.7.2.Final > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2952) LRA rest cdi checker should not demand @Status

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2952?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2952. ------------------------------- > LRA rest cdi checker should not demand @Status > ---------------------------------------------- > > Key: JBTM-2952 > URL: https://issues.jboss.org/browse/JBTM-2952 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > The LRA cdi checker expects the `@Status` annotation being compulsory for LRA annotated class. That is not true and `@Status` is not required. > In addition it would be good to consider check for async completion (usage of `@Suspended`) where `@Status` is in contrary expected. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2951: -------------------------------- Fix Version/s: 5.7.2.Final > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2951) Application using LRAClient starts with multiple warnings

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2951?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2951. ------------------------------- > Application using LRAClient starts with multiple warnings > --------------------------------------------------------- > > Key: JBTM-2951 > URL: https://issues.jboss.org/browse/JBTM-2951 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Priority: Minor > Fix For: 5.7.2.Final > > > When starting an application using {{LRAClient}} I get several warnings during startup > {code} > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRARequestFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,521 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ClientLRAResponseFilter is already registered. 2nd registration is being ignored. > 2017-10-30 08:25:34,551 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ServerService Thread Pool -- 5) RESTEASY002155: Provider class io.narayana.lra.filter.ServerLRAFilter is already registered. 2nd registration is being ignored. > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.... ] Tom Jenkinson closed JBTM-2954. ------------------------------- > LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204 > -------------------------------------------------------------------------------------------------------------- > > Key: JBTM-2954 > URL: https://issues.jboss.org/browse/JBTM-2954 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.7.1.Final > Reporter: Ondra Chaloupka > Assignee: Ondra Chaloupka > Fix For: 5.7.2.Final > > > If you a status check from the lra coordinator then you will receive this warning if the client does not define {{Accept}} header. > {code} > WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods match request "GET /lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching methods: [public javax.ws.rs.core.Response io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws javax.ws.rs.NotFoundException] > {code} > The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag - {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)Produces(MediaType.APPLICATION_JSON)}}. > If client does not specify the {{Accept}} http header then I think is expected to get text plain. That works this way now but because of the ambiguity it's not guaranteed. > I was thinking to use JAX-RS header manual validation - {{@HeaderParam("accept")}} but the both methods work a bit differently in case of active LRA which was not asked to finish. I'm not sure how to merge them. {{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}} and the {{202}} is then part of the the json body. > {code} > HTTP/1.1 200 OK > Connection: keep-alive > Content-Type: application/json > Content-Length: 359 > Date: Mon, 06 Nov 2017 09:14:44 GMT > {"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true} > {code} > Here could be seen another discrepancy that json returns http status {{202}} (https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordina...) (as said above the real http return status is {{200}}). The the code in the coordinator seems to count to return code {{Response.noContent()}} which is {{204}} but the comments refers to {{202}}. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-2956) Add a simple pooling datasource wrapper

by Tom Jenkinson (JIRA)

[ https://issues.jboss.org/browse/JBTM-2956?page=com.atlassian.jira.plugin.... ] Tom Jenkinson updated JBTM-2956: -------------------------------- Fix Version/s: 5.7.2.Final (was: 5.next) > Add a simple pooling datasource wrapper > --------------------------------------- > > Key: JBTM-2956 > URL: https://issues.jboss.org/browse/JBTM-2956 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Testing > Reporter: Tom Jenkinson > Assignee: Tom Jenkinson > Fix For: 5.7.2.Final > > > Due to move to containerized databases we see that some of the databases can be somewhat constrained with transient connection failures. We can alleviate that slightly with a simple pooling wrapper. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

6 years, 10 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues January 2018