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 commented on JBTM-3293: ---------------------------------------- [~mstefank] ok, I see. Would then make sense to consider of not publishing the {{jar}} archive type to Maven nexus but only the {{war}} archive. And using the jar only as a deliverable for the internal projects? Or are not the thorntail and quarkus capable to work with {{war}} in the same way as with {{jar}}? (I assume here that the jar is now consumed only for the Narayana purposes. When consumed e.g. by OpenLiberty it's wrong as the {{war}} should be provided for them.) > 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, 10 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: --------------------------------------- [~ochaloup] yes, it does. Changing the packaging to war fixes this issue. However, I would prefer to add a new module rather than change the packaging of the existing lra-coordinator-jar module as this module is used in quarkus and thorntail deliverables. > 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, 10 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: ---------------------------------------- [~mstefank] By me it makes much of sense. As the LRA coordinator provides the JAX-RS HTTP endpoints it should be defined as war archive. Have you tried that the changing from {{jar}} to {{war}} fixes the issue? If it so i would be for to change the archive type to {{war}}. > 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, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3300) Enable the checkstyle plugin on as many non Arjuna modules as makes sense

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3300?page=com.atlassian.jira.plugin... ] Michael Musgrove closed JBTM-3300. ---------------------------------- Resolution: Rejected Rejecting in favour of the following policy that we've been following since 2005: * 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. We will add a build property called checkstyle that you can pass to the compilation. 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). We will also update the "New Pull Request" github message to reference this policy. > Enable the checkstyle plugin on as many non Arjuna modules as makes sense > ------------------------------------------------------------------------- > > Key: JBTM-3300 > URL: https://issues.redhat.com/browse/JBTM-3300 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, REST, TxBridge, XTS > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > The checkstyle plugin is intended for use on new files but it is currently disabled. We should enable for as many of our modules as possible. > Arjuna modules should be precluded. > I am not sure if we want to enable it for STM. > Note that we use the WildFly checkstyle rule set (https://github.com/wildfly/wildfly-checkstyle-config/tree/master/src/main...). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3300) Enable the checkstyle plugin on as many non Arjuna modules as makes sense

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3300?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3300: ---------------------------------------- Rejecting in favour of the following policy that we've been following since 2005: - 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. We will add a build property called checkstyle that you can pass to the compilation. 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). We will also update the "New Pull Request" github message to reference this policy. > Enable the checkstyle plugin on as many non Arjuna modules as makes sense > ------------------------------------------------------------------------- > > Key: JBTM-3300 > URL: https://issues.redhat.com/browse/JBTM-3300 > Project: JBoss Transaction Manager > Issue Type: Task > Components: LRA, REST, TxBridge, XTS > Affects Versions: 5.10.4.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Optional > Fix For: 5.next > > > The checkstyle plugin is intended for use on new files but it is currently disabled. We should enable for as many of our modules as possible. > Arjuna modules should be precluded. > I am not sure if we want to enable it for STM. > Note that we use the WildFly checkstyle rule set (https://github.com/wildfly/wildfly-checkstyle-config/tree/master/src/main...). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3300) Enable the checkstyle plugin on as many non Arjuna modules as makes sense

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3300: -------------------------------------- Summary: Enable the checkstyle plugin on as many non Arjuna modules as makes sense Key: JBTM-3300 URL: https://issues.redhat.com/browse/JBTM-3300 Project: JBoss Transaction Manager Issue Type: Task Components: LRA, REST, TxBridge, XTS Affects Versions: 5.10.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next The checkstyle plugin is intended for use on new files but it is currently disabled. We should enable for as many of our modules as possible. Arjuna modules should be precluded. I am not sure if we want to enable it for STM. Note that we use the WildFly checkstyle rule set (https://github.com/wildfly/wildfly-checkstyle-config/tree/master/src/main...). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3269) Make Narayana commit markable resource quickstart working with JDK9+

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3269?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3269: ----------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/270, https://github.com/jbosstm/quickstart/pull/279 (was: https://github.com/jbosstm/quickstart/pull/270) > Make Narayana commit markable resource quickstart working with JDK9+ > -------------------------------------------------------------------- > > Key: JBTM-3269 > URL: https://issues.redhat.com/browse/JBTM-3269 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Quickstarts > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > Fix For: 5.next > > > The quickstart `wildfly/commit-markable-resource` fails with > {quote} > Failed to execute goal on project commit-markable-resource: Could not resolve dependencies for project org.jboss.narayana.quickstarts:commit-markable-resource:war:5.10.5.Final-SNAPSHOT: Could not find artifact com.sun:tools:jar:1.6.0 at specified path /opt/jdk-9.0.4/../lib/tools.jar > {quote} > on JDK9. > It's caused by the fact that the Arquillian Byteman Extension uses call {{VirtualMachine.attach(pid)}} which is handled differently on JDK9+. > See https://github.com/arquillian/arquillian-extension-byteman/blob/master/po... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3122) jbosstm/quickstarts tests can't be run with jdk9+

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3122?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3122: -------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/278 (was: https://github.com/jbosstm/quickstart/pull/267) > jbosstm/quickstarts tests can't be run with jdk9+ > ------------------------------------------------- > > Key: JBTM-3122 > URL: https://issues.redhat.com/browse/JBTM-3122 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: Build System > Affects Versions: 5.9.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > Quickstarts do not run tests with JDK9+. We use the Arquillian that starts the WildFly and for the JDK9+ it requires JVM options to add module permissions (and more). > The quickstarts need to start using a profile, similar how WFLY uses it, that defines jvm args that will be passed to the {{arquillian.xml}}. > See https://github.com/wildfly/wildfly/blob/16.0.0.Final/pom.xml#L7188 > {code} > --add-exports=java.base/sun.nio.ch=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.reflect=ALL-UNNAMED > --add-exports=jdk.unsupported/sun.misc=ALL-UNNAMED > --add-modules=java.se > {code} > The trouble in quickstarts is that we have no parent for the quickstarts so we need to add such profile to all the `pom.xml` files all over the quickstarts. > Maybe we should provide a parent with such settings. We can unify not only this but e.g. ee version used or arquillian version. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3132) Common parent maven module for Narayana quickstarts

by Mayank Kunwar (Jira)

[ https://issues.redhat.com/browse/JBTM-3132?page=com.atlassian.jira.plugin... ] Mayank Kunwar updated JBTM-3132: -------------------------------- Git Pull Request: https://github.com/jbosstm/quickstart/pull/278 (was: https://github.com/jbosstm/quickstart/pull/267) > Common parent maven module for Narayana quickstarts > --------------------------------------------------- > > Key: JBTM-3132 > URL: https://issues.redhat.com/browse/JBTM-3132 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Testing > Affects Versions: 5.9.5.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > It would be beneficial to create a common quickstart maven module. > My intention is to have a one place where we can define: > * common profiles could be defined (one of such profile is Arquillian JDK9+ which defines JVM arguments needed for smooth run of tests, see https://issues.jboss.org/projects/JBTM/issues/JBTM-3122) > * common properties like arquillian version. This has benefit that quickstarts will run faster on CI as there won't be multiple versions to be downloaded. > * common repositories like jboss one > * unified checkstyle definition for all the quickstarts would be coded in one way which makes them easier to read > The quickstarts were designed to be independent on each other. The task is not to unified them. The proposal is about creating a place where a common stuff can be placed to. Otherwise the same configuration needs to be copied to multiple places. Which is hard to maintain > Other projects, e.g. WildFly, use the same approach of common parent, see https://github.com/wildfly/quickstart/blob/master/app-client/pom.xml -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 10 months

1
0
0 / 0

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

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3299: ------------------------------------- Summary: 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 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, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

jbossts-issues April 2020