[JBoss JIRA] (JBTM-3290) ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3290?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3290:
-----------------------------------
Status: Pull Request Sent (was: Open)
Git Pull Request: https://github.com/jbosstm/quickstart/pull/275
> ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
> ----------------------------------------------------------------------------
>
> Key: JBTM-3290
> URL: https://issues.redhat.com/browse/JBTM-3290
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 5.10.4.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Attachments: consoleText.zip
>
>
> When our AMS CI is slower then the quickstart {{ArjunaJTS/interop/glassfish}} consistently fails with error
> {code}
> [0m[ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
> at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:804)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:751)
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:313)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3290) ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3290?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3290:
-----------------------------------
Attachment: consoleText.zip
> ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
> ----------------------------------------------------------------------------
>
> Key: JBTM-3290
> URL: https://issues.redhat.com/browse/JBTM-3290
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: Quickstarts
> Affects Versions: 5.10.4.Final
> Reporter: Ondrej Chaloupka
> Assignee: Ondrej Chaloupka
> Priority: Minor
> Attachments: consoleText.zip
>
>
> When our AMS CI is slower then the quickstart {{ArjunaJTS/interop/glassfish}} consistently fails with error
> {code}
> [0m[ERROR] Command execution failed.
> org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
> at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
> at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:804)
> at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:751)
> at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:313)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3290) ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
by Ondrej Chaloupka (Jira)
Ondrej Chaloupka created JBTM-3290:
--------------------------------------
Summary: ArjunaJTS/interop/glassfish fails on CI with Process exited with an error: 1
Key: JBTM-3290
URL: https://issues.redhat.com/browse/JBTM-3290
Project: JBoss Transaction Manager
Issue Type: Bug
Components: Quickstarts
Affects Versions: 5.10.4.Final
Reporter: Ondrej Chaloupka
Assignee: Ondrej Chaloupka
When our AMS CI is slower then the quickstart {{ArjunaJTS/interop/glassfish}} consistently fails with error
{code}
[0m[ERROR] Command execution failed.
org.apache.commons.exec.ExecuteException: Process exited with an error: 1 (Exit value: 1)
at org.apache.commons.exec.DefaultExecutor.executeInternal(DefaultExecutor.java:404)
at org.apache.commons.exec.DefaultExecutor.execute(DefaultExecutor.java:166)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:804)
at org.codehaus.mojo.exec.ExecMojo.executeCommandLine(ExecMojo.java:751)
at org.codehaus.mojo.exec.ExecMojo.execute(ExecMojo.java:313)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:160)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
{code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3273) Avoid implementing InvocationHandler in jtaLogger
by Mayank Kunwar (Jira)
[ https://issues.redhat.com/browse/JBTM-3273?page=com.atlassian.jira.plugin... ]
Mayank Kunwar commented on JBTM-3273:
-------------------------------------
Removed InvocationHandler from jtaLogger. Hopefully now it would help in optimizing Narayana for GraalVM.
> Avoid implementing InvocationHandler in jtaLogger
> -------------------------------------------------
>
> Key: JBTM-3273
> URL: https://issues.redhat.com/browse/JBTM-3273
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTA
> Reporter: Sanne Grinovero
> Assignee: Mayank Kunwar
> Priority: Major
>
> Context: optimisations for Quarkus
> Class {{com.arjuna.ats.jta.logging.jtaLogger}} is implementing {{InvocationHandler}}, and this is causing some difficulties in optimising Narayana for GraalVM native images.
> One problem is that all classes which use the logger have access to the {{InvocationHandler}}, which makes the analysis phase of the compiler quite more complex; this gets confusing when there is a compilation failure as this gets occasionally reported as the root cause (even though it's just one of the paths leading to a non-real issue).
> A secondary problem is that this class is inizializing a rather expensive proxy; this is less important but it would be great for the sake of bootstrap optimisations to refactor the {{i18NLogger}} field to not be a proxy.
> See also https://github.com/quarkusio/quarkus/pull/5343 : with such invocation handlers being widely reachable, it's very hard to support its native compilation.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3287) ThornTail LRA coordinator cannot start
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3287?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on JBTM-3287 at 4/15/20 5:42 AM:
-----------------------------------------------------------------
This was a pretty strange behaviour and I was wondering what's the cause of the failure.
The start-up error on Thorntail coordinator provides information there is some trouble of the dependencies lookup
{code}
ERROR [org.wildfly.swarm.modules.application] (main) Unable to find artifact for org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20200414.093442-754
{code}
When we list the content of the jar then we can see there is duplicate of the included artifacts which seems to cause the error
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/microprofile-lra-api-1.0-20200414.093442-754.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/
{quote}
After the fix provided by https://github.com/jbosstm/narayana/commit/ec3b90955347d20a1ccede85f3a664... the content of the final jar file is simplier
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22425 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
{quote}
Which means no duplicate, no trouble.
At start when I saw this issue I was thinking we need to have some dependency discrepancy in the LRA maven module provided. And it was the reason I started to investigate a bit more.
But as I was searching around I think it's just a normal maven behaviour. When I run `dependency:tree` on both versions - with the fix and before the fix then the result is absolutely same.
{code}
mvn clean dependency:tree -Dincludes=org.eclipse.microprofile.lra:microprofile-lra-api
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ lra-coordinator-thorntail ---
[INFO] org.jboss.narayana.rts:lra-coordinator-thorntail:war:5.10.5.Final-SNAPSHOT
[INFO] \- org.jboss.narayana.rts:lra-coordinator-jar:jar:5.10.5.Final-SNAPSHOT:compile
[INFO] \- org.eclipse.microprofile.lra:microprofile-lra-api:jar:1.0-SNAPSHOT:compile
{code}
(The same depenency:tree result can be observed on any lra maven module).
In both cases there is resolved the version to {{1.0-SNAPSHOT}}. The reason here seems to be with the maven version resolution. I think (just I can't find whole the relevant info about exact rules) that the version {{1.0-20200414.093442-754}} as not defined as {{Final}} is resolved to {{SNAPSHOT}}.
(When I deleted my {{m2}} repo and run {{mvn install}} with the fix involved then I can see the {{1.0-SNAPSHOT}} was installed at ~/.m2/repository/org/eclipse/microprofile/lra/microprofile-lra-api/)
This behaviour could be a maven dependency plugin issue. Even for the newest version {{3.1.2}} I can see the same behaviour. So I'm not sure here.
There could be the issue of how Thorntail resolves this SNAPSHOT depenedencies as it could be using the maven approach and for transitive dependencies it's the direct "download". Not sure again.
In summary, the version definitions seems to be correct for the LRA modules. When the explicit definition of the lra api version is done in the Thorntail module then all works fine. With version which is {{Final}} or {{RC1}} it works correctly without need to explicitly define the version in the {{pom.xml}} of the thorntail module.
I don't think there is much reason to investigate more around.
**I'm removing intentionally the affected version!**
The trouble can be observed only on the LRA branch where the snapshot version of the LRA api was used. The `5.10.4.Final` uses the {{-RC1}} version for the API and the thorntail coordinator works fine there.
was (Author: ochaloup):
This was a pretty strange behaviour and I was wondering what's the cause of the failure.
The start-up error on Thorntail coordinator provides information there is some trouble of the dependencies lookup
{code}
ERROR [org.wildfly.swarm.modules.application] (main) Unable to find artifact for org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20200414.093442-754
{code}
When we list the content of the jar then we can see there is duplicate of the included artifacts which seems to cause the error
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/microprofile-lra-api-1.0-20200414.093442-754.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/
{quote}
After the fix provided by https://github.com/jbosstm/narayana/commit/ec3b90955347d20a1ccede85f3a664... the content of the final jar file is simplier
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22425 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
{quote}
Which means no duplicate, no trouble.
At start when I saw this issue I was thinking we need to have some dependency discrepancy in the LRA maven module provided. And it was the reason I started to investigate a bit more.
But as I was searching around I think it's just a normal maven behaviour. When I run `dependency:tree` on both versions - with the fix and before the fix then the result is absolutely same.
{code}
mvn clean dependency:tree -Dincludes=org.eclipse.microprofile.lra:microprofile-lra-api
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ lra-coordinator-thorntail ---
[INFO] org.jboss.narayana.rts:lra-coordinator-thorntail:war:5.10.5.Final-SNAPSHOT
[INFO] \- org.jboss.narayana.rts:lra-coordinator-jar:jar:5.10.5.Final-SNAPSHOT:compile
[INFO] \- org.eclipse.microprofile.lra:microprofile-lra-api:jar:1.0-SNAPSHOT:compile
{code}
(The same depenency:tree result can be observed on any lra maven module).
In both cases there is resolved the version to {{1.0-SNAPSHOT}}. The reason here seems to be with the maven version resolution. I think (just I can't find whole the relevant info about exact rules) that the version {{1.0-20200414.093442-754}} as not defined as {{Final}} is resolved to {{SNAPSHOT}}.
This behaviour could be a maven dependency plugin issue. Even for the newest version {{3.1.2}} I can see the same behaviour. So I'm not sure here.
In summary, the version definitions seems to be correct for the LRA modules. When the explicit definition of the lra api version is done in the Thorntail module then all works fine. With version which is {{Final}} or {{RC1}} it works correctly without need to explicitly define the version in the {{pom.xml}} of the thorntail module.
I don't think there is much reason to investigate more around.
**I'm removing intentionally the affected version!**
The trouble can be observed only on the LRA branch where the snapshot version of the LRA api was used. The `5.10.4.Final` uses the {{-RC1}} version for the API and the thorntail coordinator works fine there.
> ThornTail LRA coordinator cannot start
> --------------------------------------
>
> Key: JBTM-3287
> URL: https://issues.redhat.com/browse/JBTM-3287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
> {noformat}
> It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3287) ThornTail LRA coordinator cannot start
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3287?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka edited comment on JBTM-3287 at 4/15/20 5:23 AM:
-----------------------------------------------------------------
This was a pretty strange behaviour and I was wondering what's the cause of the failure.
The start-up error on Thorntail coordinator provides information there is some trouble of the dependencies lookup
{code}
ERROR [org.wildfly.swarm.modules.application] (main) Unable to find artifact for org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20200414.093442-754
{code}
When we list the content of the jar then we can see there is duplicate of the included artifacts which seems to cause the error
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/microprofile-lra-api-1.0-20200414.093442-754.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/
{quote}
After the fix provided by https://github.com/jbosstm/narayana/commit/ec3b90955347d20a1ccede85f3a664... the content of the final jar file is simplier
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22425 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
{quote}
Which means no duplicate, no trouble.
At start when I saw this issue I was thinking we need to have some dependency discrepancy in the LRA maven module provided. And it was the reason I started to investigate a bit more.
But as I was searching around I think it's just a normal maven behaviour. When I run `dependency:tree` on both versions - with the fix and before the fix then the result is absolutely same.
{code}
mvn clean dependency:tree -Dincludes=org.eclipse.microprofile.lra:microprofile-lra-api
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ lra-coordinator-thorntail ---
[INFO] org.jboss.narayana.rts:lra-coordinator-thorntail:war:5.10.5.Final-SNAPSHOT
[INFO] \- org.jboss.narayana.rts:lra-coordinator-jar:jar:5.10.5.Final-SNAPSHOT:compile
[INFO] \- org.eclipse.microprofile.lra:microprofile-lra-api:jar:1.0-SNAPSHOT:compile
{code}
(The same depenency:tree result can be observed on any lra maven module).
In both cases there is resolved the version to {{1.0-SNAPSHOT}}. The reason here seems to be with the maven version resolution. I think (just I can't find whole the relevant info about exact rules) that the version {{1.0-20200414.093442-754}} as not defined as {{Final}} is resolved to {{SNAPSHOT}}.
This behaviour could be a maven dependency plugin issue. Even for the newest version {{3.1.2}} I can see the same behaviour. So I'm not sure here.
In summary, the version definitions seems to be correct for the LRA modules. When the explicit definition of the lra api version is done in the Thorntail module then all works fine. With version which is {{Final}} or {{RC1}} it works correctly without need to explicitly define the version in the {{pom.xml}} of the thorntail module.
I don't think there is much reason to investigate more around.
**I'm removing intentionally the affected version!**
The trouble can be observed only on the LRA branch where the snapshot version of the LRA api was used. The `5.10.4.Final` uses the {{-RC1}} version for the API and the thorntail coordinator works fine there.
was (Author: ochaloup):
This was a pretty strange behaviour and I was wondering what's the cause of the failure.
The start-up error on Thorntail coordinator provides information there is some trouble of the dependencies lookup
{code}
ERROR [org.wildfly.swarm.modules.application] (main) Unable to find artifact for org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20200414.093442-754
{code}
When we list the content of the jar then we can see there is duplicate of the included artifacts which seems to cause the error
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/microprofile-lra-api-1.0-20200414.093442-754.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/
{quote}
After the fix provided by https://github.com/jbosstm/narayana/commit/ec3b90955347d20a1ccede85f3a664... the content of the final jar file is simplier
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22425 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
{quote}
Which means no duplicate, no trouble.
At start when I saw this issue I was thinking we need to have some dependency discrepancy in the LRA maven module provided. And it was the reason I started to investigate a bit more.
But as I was searching around I think it's just a normal maven behaviour. When I run `dependency:tree` on both versions - with the fix and before the fix then the result is absolutely same.
{code}
mvn clean dependency:tree -Dincludes=org.eclipse.microprofile.lra:microprofile-lra-api
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ lra-coordinator-thorntail ---
[INFO] org.jboss.narayana.rts:lra-coordinator-thorntail:war:5.10.5.Final-SNAPSHOT
[INFO] \- org.jboss.narayana.rts:lra-coordinator-jar:jar:5.10.5.Final-SNAPSHOT:compile
[INFO] \- org.eclipse.microprofile.lra:microprofile-lra-api:jar:1.0-SNAPSHOT:compile
{code}
(The same depenency:tree result can be observed on any lra maven module).
In both cases there is resolved the version to {{1.0-SNAPSHOT}}. The reason here seems to be with the maven version resolution. I think (just I can't find whole the relevant info about exact rules) that the version {{1.0-20200414.093442-754}} as not defined as {{Final}} is resolved to {{SNAPSHOT}}.
This behaviour could be an maven dependency plugin issue but even for the newest version {{3.1.2}} I can see the same behaviour.
In summary, the version definitions seems to be correct for the LRA modules. When the explicit definition of the lra api version is done in the Thorntail module then all works fine. With version which is {{Final}} or {{RC1}} it works correctly without need to explicitly define the version in the {{pom.xml}} of the thorntail module.
I don't think there is much reason to investigate more around.
**I'm removing intentionally the affected version!**
The trouble can be observed only on the LRA branch where the snapshot version of the LRA api was used. The `5.10.4.Final` uses the {{-RC1}} version for the API and the thorntail coordinator works fine there.
> ThornTail LRA coordinator cannot start
> --------------------------------------
>
> Key: JBTM-3287
> URL: https://issues.redhat.com/browse/JBTM-3287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
> {noformat}
> It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3287) ThornTail LRA coordinator cannot start
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3287?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka commented on JBTM-3287:
----------------------------------------
This was a pretty strange behaviour and I was wondering what's the cause of the failure.
The start-up error on Thorntail coordinator provides information there is some trouble of the dependencies lookup
{code}
ERROR [org.wildfly.swarm.modules.application] (main) Unable to find artifact for org.eclipse.microprofile.lra:microprofile-lra-api:1.0-20200414.093442-754
{code}
When we list the content of the jar then we can see there is duplicate of the included artifacts which seems to cause the error
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
22421 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/microprofile-lra-api-1.0-20200414.093442-754.jar
0 04-15-2020 11:04 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-20200414.093442-754/
{quote}
After the fix provided by https://github.com/jbosstm/narayana/commit/ec3b90955347d20a1ccede85f3a664... the content of the final jar file is simplier
{quote}
unzip -l target/lra-coordinator-thorntail.jar | grep api | grep lra
22425 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/microprofile-lra-api-1.0-SNAPSHOT.jar
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/
0 04-15-2020 10:51 m2repo/org/eclipse/microprofile/lra/microprofile-lra-api/1.0-SNAPSHOT/
{quote}
Which means no duplicate, no trouble.
At start when I saw this issue I was thinking we need to have some dependency discrepancy in the LRA maven module provided. And it was the reason I started to investigate a bit more.
But as I was searching around I think it's just a normal maven behaviour. When I run `dependency:tree` on both versions - with the fix and before the fix then the result is absolutely same.
{code}
mvn clean dependency:tree -Dincludes=org.eclipse.microprofile.lra:microprofile-lra-api
[INFO] --- maven-dependency-plugin:3.1.1:tree (default-cli) @ lra-coordinator-thorntail ---
[INFO] org.jboss.narayana.rts:lra-coordinator-thorntail:war:5.10.5.Final-SNAPSHOT
[INFO] \- org.jboss.narayana.rts:lra-coordinator-jar:jar:5.10.5.Final-SNAPSHOT:compile
[INFO] \- org.eclipse.microprofile.lra:microprofile-lra-api:jar:1.0-SNAPSHOT:compile
{code}
(The same depenency:tree result can be observed on any lra maven module).
In both cases there is resolved the version to {{1.0-SNAPSHOT}}. The reason here seems to be with the maven version resolution. I think (just I can't find whole the relevant info about exact rules) that the version {{1.0-20200414.093442-754}} as not defined as {{Final}} is resolved to {{SNAPSHOT}}.
This behaviour could be an maven dependency plugin issue but even for the newest version {{3.1.2}} I can see the same behaviour.
In summary, the version definitions seems to be correct for the LRA modules. When the explicit definition of the lra api version is done in the Thorntail module then all works fine. With version which is {{Final}} or {{RC1}} it works correctly without need to explicitly define the version in the {{pom.xml}} of the thorntail module.
I don't think there is much reason to investigate more around.
**I'm removing intentionally the affected version!**
The trouble can be observed only on the LRA branch where the snapshot version of the LRA api was used. The `5.10.4.Final` uses the {{-RC1}} version for the API and the thorntail coordinator works fine there.
> ThornTail LRA coordinator cannot start
> --------------------------------------
>
> Key: JBTM-3287
> URL: https://issues.redhat.com/browse/JBTM-3287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
> {noformat}
> It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3287) ThornTail LRA coordinator cannot start
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3287?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3287:
-----------------------------------
Description:
{noformat}
Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
{noformat}
It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
was:
{noformat}
Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
{noformat}
It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
Git Pull Request: https://github.com/jbosstm/narayana/pull/1597
> ThornTail LRA coordinator cannot start
> --------------------------------------
>
> Key: JBTM-3287
> URL: https://issues.redhat.com/browse/JBTM-3287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
> {noformat}
> It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years
[JBoss JIRA] (JBTM-3287) ThornTail LRA coordinator cannot start
by Ondrej Chaloupka (Jira)
[ https://issues.redhat.com/browse/JBTM-3287?page=com.atlassian.jira.plugin... ]
Ondrej Chaloupka updated JBTM-3287:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Fix Version/s: 5.next
Resolution: Done
> ThornTail LRA coordinator cannot start
> --------------------------------------
>
> Key: JBTM-3287
> URL: https://issues.redhat.com/browse/JBTM-3287
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Reporter: Martin Stefanko
> Assignee: Martin Stefanko
> Priority: Major
> Fix For: 5.next
>
>
> {noformat}
> Caused by: java.lang.NoClassDefFoundError: org/eclipse/microprofile/lra/annotation/LRAStatus
> {noformat}
> It seems that the LRA API dependency needs to be defined directly in the lra-coordinator-thorntail module. It isn't picked up from transitive dependency (lra-coordinator-jar).
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
4 years