April 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3293 at 4/22/20 8:16 AM: ----------------------------------------------------------------- I see the point. I'm just a bit concerned about the fact there will be two same artifacts which are just published in different way. There could be a the trouble to understand why there are two and what's the difference. I understand the fact about the maven dependecy and ease of handling for the jar. Ok, then from what was discussed here I agree that we need to have two artifact being published. The only other minor thing which came to my mind if we need to have two separate maven modules or this will be just in one. But it's probably only a matter of taste and it does not seem being important. was (Author: ochaloup): I see the point. I'm just a bit concerned about the fact there will be two same artifacts which are just published in different way. There could be a the trouble to understand why there are two and what's the difference. I understand the fact about the maven dependecy and ease of handling for the jar. Ok, then from what was discussed here I agree that we need to have two artifact being published. The only other minor thing which came to my mind if we need to have two separate maven modules or this will be just in one. > LRA coordinator jar cannot be deployed on WildFly > ------------------------------------------------- > > Key: JBTM-3293 > URL: https://issues.redhat.com/browse/JBTM-3293 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error: > {noformat} > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService > at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0) > WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader]. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3293: ---------------------------------------- I see the point. I'm just a bit concerned about the fact there will be two same artifacts which are just published in different way. There could be a the trouble to understand why there are two and what's the difference. I understand the fact about the maven dependecy and ease of handling for the jar. Ok, then from what was discussed here I agree that we need to have two artifact being published. The only other minor thing which came to my mind if we need to have two separate maven modules or this will be just in one. > LRA coordinator jar cannot be deployed on WildFly > ------------------------------------------------- > > Key: JBTM-3293 > URL: https://issues.redhat.com/browse/JBTM-3293 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error: > {noformat} > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService > at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0) > WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader]. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3301) Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3301?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3301: ----------------------------------- Status: Pull Request Sent (was: Open) > Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11 > ------------------------------------------------------------------------------------------ > > Key: JBTM-3301 > URL: https://issues.redhat.com/browse/JBTM-3301 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Current Tomcat related quickstarts in the Narayana quickstart repo https://github.com/jbosstm/quickstart/tree/5.10.4.Final > First, use the old integration code of the Narayana-Tomcat from time the integration code was part of the Narayana repo (https://github.com/jbosstm/narayana/tree/5.9.0.Final/tomcat) > But now it's separated under the standalone project here https://github.com/web-servers/narayana-tomcat > There is a small trouble with this change as the code for JWS requires a newer version of the Tomcat than it's used in the quickstart now. The Tomcate version update from {{9.0.4}} to up-to-date version is needed as well. > The Tomcat quickstart does not start on JDK9+ as the newer JDK misses the JAX-B classes directly in the JDK. The dependencies need to be provided as part of the {{war}} archive (or provided to Tomcat classpath in other way). > A small trouble on the {{run.sh}} shell script used for quickstart execution is that if {{TOMCAT_HOME}} is placed on a path with space in name it fails as the path is not encapsulated with parentheses {{"}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3301) Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3301?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3301: ----------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/280 > Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11 > ------------------------------------------------------------------------------------------ > > Key: JBTM-3301 > URL: https://issues.redhat.com/browse/JBTM-3301 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > Current Tomcat related quickstarts in the Narayana quickstart repo https://github.com/jbosstm/quickstart/tree/5.10.4.Final > First, use the old integration code of the Narayana-Tomcat from time the integration code was part of the Narayana repo (https://github.com/jbosstm/narayana/tree/5.9.0.Final/tomcat) > But now it's separated under the standalone project here https://github.com/web-servers/narayana-tomcat > There is a small trouble with this change as the code for JWS requires a newer version of the Tomcat than it's used in the quickstart now. The Tomcate version update from {{9.0.4}} to up-to-date version is needed as well. > The Tomcat quickstart does not start on JDK9+ as the newer JDK misses the JAX-B classes directly in the JDK. The dependencies need to be provided as part of the {{war}} archive (or provided to Tomcat classpath in other way). > A small trouble on the {{run.sh}} shell script used for quickstart execution is that if {{TOMCAT_HOME}} is placed on a path with space in name it fails as the path is not encapsulated with parentheses {{"}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3302) New PR job text should include our policy on running checkstyle

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3302: -------------------------------------- Summary: New PR job text should include our policy on running checkstyle Key: JBTM-3302 URL: https://issues.redhat.com/browse/JBTM-3302 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Build System Affects Versions: 5.10.4.Final Reporter: Michael Musgrove Fix For: 5.next The PR text should include the following: {quote} Our style rules for submitting code are as follows: * If you add a new file it MUST adhere to our checkstyle ruleset. * If you change a file (in a non trivial way) you are allowed (MAY) to reformat the code to conform to our checkstyle ruleset. If you choose not to reformat it then you SHOULD, where possible, try to follow the same style that's already in use for that file. Checkstyle is enabled via a boolean property "-Dcheckstyle" to the compilation. {quote} Note that we need our own property because you cannot override a plugin property that is already set in the plugin configuration section (ie -Dcheckstyle.skip=false does not work). The fix for this issue should include our new -Dcheckstyle property . -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3301) Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3301: -------------------------------------- Summary: Adjust the Narayana Tomcat quickstarts to use the JWS integration and for working on JDK11 Key: JBTM-3301 URL: https://issues.redhat.com/browse/JBTM-3301 Project: JBoss Transaction Manager Issue Type: Bug Components: Quickstarts Affects Versions: 5.10.4.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka Current Tomcat related quickstarts in the Narayana quickstart repo https://github.com/jbosstm/quickstart/tree/5.10.4.Final First, use the old integration code of the Narayana-Tomcat from time the integration code was part of the Narayana repo (https://github.com/jbosstm/narayana/tree/5.9.0.Final/tomcat) But now it's separated under the standalone project here https://github.com/web-servers/narayana-tomcat There is a small trouble with this change as the code for JWS requires a newer version of the Tomcat than it's used in the quickstart now. The Tomcate version update from {{9.0.4}} to up-to-date version is needed as well. The Tomcat quickstart does not start on JDK9+ as the newer JDK misses the JAX-B classes directly in the JDK. The dependencies need to be provided as part of the {{war}} archive (or provided to Tomcat classpath in other way). A small trouble on the {{run.sh}} shell script used for quickstart execution is that if {{TOMCAT_HOME}} is placed on a path with space in name it fails as the path is not encapsulated with parentheses {{"}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3299) Expose optional additional description of LRARecord status

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3299?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on JBTM-3299: --------------------------------------- [~mmusgrov] yes, that is the plan. > Expose optional additional description of LRARecord status > ---------------------------------------------------------- > > Key: JBTM-3299 > URL: https://issues.redhat.com/browse/JBTM-3299 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The LRA record can be in a state, for instance, Completing or Compensating into which it got based on different criteria: > * on users request (by user returning 202 status code from Complete or Compensate method) > * because the Complete or Compensate invocation didn't succeed and the coordinator will retry in the next recovery run > This distinction may be useful for users querying LRAs so we can include it in the JSON response representing the LRARecord. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3299) Expose optional additional description of LRARecord status

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3299?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3299: ---------------------------------------- Will you also add a field to the JSON response to include an array of strings corresponding to any failed participants. > Expose optional additional description of LRARecord status > ---------------------------------------------------------- > > Key: JBTM-3299 > URL: https://issues.redhat.com/browse/JBTM-3299 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The LRA record can be in a state, for instance, Completing or Compensating into which it got based on different criteria: > * on users request (by user returning 202 status code from Complete or Compensate method) > * because the Complete or Compensate invocation didn't succeed and the coordinator will retry in the next recovery run > This distinction may be useful for users querying LRAs so we can include it in the JSON response representing the LRARecord. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Martin Stefanko commented on JBTM-3293: --------------------------------------- The jar artifact can still be consumed in other runtimes/user applications if they want to so I would strongly suggest keeping publishing this artifact. The war module I proposed makes sense only for WFLY deployments. I haven't tested other similar runtimes. But this issue was about deploying this artifact to the wildfly server. A user can do the same add a lra-coordinator-jar dependency to their war archive together with narayana-lra dependency and a bunch of other dependencies they may need. In my experience I've never added war packaged maven dependency so I don't know what are the correct guidelines here but I personally would prefer to have both lra-coordinator-jar and lra-coodinator-war modules. > LRA coordinator jar cannot be deployed on WildFly > ------------------------------------------------- > > Key: JBTM-3293 > URL: https://issues.redhat.com/browse/JBTM-3293 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error: > {noformat} > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService > at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0) > WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader]. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3293) LRA coordinator jar cannot be deployed on WildFly

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Martin Stefanko edited comment on JBTM-3293 at 4/21/20 9:56 AM: ---------------------------------------------------------------- The jar artifact can still be consumed in other runtimes/user applications if they want to do so I would strongly suggest keeping publishing this artifact. The war module I proposed makes sense only for WFLY deployments. I haven't tested other similar runtimes. But this issue was about deploying this artifact to the wildfly server. A user can do the same add a lra-coordinator-jar dependency to their war archive together with narayana-lra dependency and a bunch of other dependencies they may need. In my experience I've never added war packaged maven dependency so I don't know what are the correct guidelines here but I personally would prefer to have both lra-coordinator-jar and lra-coodinator-war modules. was (Author: mstefank): The jar artifact can still be consumed in other runtimes/user applications if they want to so I would strongly suggest keeping publishing this artifact. The war module I proposed makes sense only for WFLY deployments. I haven't tested other similar runtimes. But this issue was about deploying this artifact to the wildfly server. A user can do the same add a lra-coordinator-jar dependency to their war archive together with narayana-lra dependency and a bunch of other dependencies they may need. In my experience I've never added war packaged maven dependency so I don't know what are the correct guidelines here but I personally would prefer to have both lra-coordinator-jar and lra-coodinator-war modules. > LRA coordinator jar cannot be deployed on WildFly > ------------------------------------------------- > > Key: JBTM-3293 > URL: https://issues.redhat.com/browse/JBTM-3293 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > Fix For: 5.next > > > I am not sure whether this should be possible but the lra-coordinator.jar from lra-coordinator-jar module can't be deployed on latest WildFly. The deployment fails with the following error: > {noformat} > Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type LRAService with qualifiers @Default > at injection point [BackedAnnotatedField] @Inject io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService > at io.narayana.lra.coordinator.api.RecoveryCoordinator.lraService(RecoveryCoordinator.java:0) > WELD-001474: Class io.narayana.lra.coordinator.domain.service.LRAService is on the classpath, but was ignored because a class it references was not found: com.arjuna.ats.arjuna.recovery.RecoveryModule from [Module "deployment.lra-coordinator.jar" from Service Module Loader]. > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 8 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 April 2020