April 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3295) LRACDIExtension returns null as class name when @LRA annotated class does not contain Compensate or AfterLRA

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3295: -------------------------------------- Summary: LRACDIExtension returns null as class name when @LRA annotated class does not contain Compensate or AfterLRA Key: JBTM-3295 URL: https://issues.redhat.com/browse/JBTM-3295 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka When the {{@LRA}} annotated class does not containe neither {{@Compensate}} nor {{@AfterLRA}} the exception message contains {{null}} instead of the name of the guilty class. {code} Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions: Exception 0 : java.lang.IllegalStateException: null: The class contains an LRA method and no Compensate or AfterLRA method was found. at io.narayana.lra.client.internal.proxy.nonjaxrs.LRACDIExtension.isLRAParticipant(LRACDIExtension.java:129) at io.narayana.lra.client.internal.proxy.nonjaxrs.LRACDIExtension.getAsParticipant(LRACDIExtension.java:104) at io.narayana.lra.client.internal.proxy.nonjaxrs.LRACDIExtension.observe(LRACDIExtension.java:75) {code} The reason seems to be that the method {{ClassInfo.simpleName()}} returns null if it's not an inner class or nested class. The javadoc says following on it {code} Returns the source declared name of this class if it is an inner class, or a local class. Otherwise this method will return null. {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[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: Resolved (was: Pull Request Sent) Fix Version/s: 5.next Resolution: Done > 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 > Fix For: 5.next > > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3273) Avoid implementing InvocationHandler in jtaLogger

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3273?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3273: ----------------------------------- Git Pull Request: https://github.com/jbosstm/narayana/pull/1590, https://github.com/jbosstm/narayana/pull/1600 > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3168) MP-LRA response codes changes

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3168?page=com.atlassian.jira.plugin... ] Michael Musgrove closed JBTM-3168. ---------------------------------- Resolution: Incomplete Description > MP-LRA response codes changes > ----------------------------- > > Key: JBTM-3168 > URL: https://issues.redhat.com/browse/JBTM-3168 > Project: JBoss Transaction Manager > Issue Type: Feature Request > Reporter: Michael Musgrove > Priority: Major > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3276) add SlotStore ObjectStore implementation

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3276?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3276: ----------------------------------- Fix Version/s: 5.next > add SlotStore ObjectStore implementation > ---------------------------------------- > > Key: JBTM-3276 > URL: https://issues.redhat.com/browse/JBTM-3276 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Transaction Core > Affects Versions: 5.10.3.Final > Reporter: Jonathan Halliday > Assignee: Jonathan Halliday > Priority: Minor > Fix For: 5.next > > > The SlotStore provides an alternative ObjectStore implementation that dispenses with the file create/open/close/delete overhead of the FileStore, whilst also eschewing the write batching of the JournalStore. This combination is particularly tailored to new persistent memory hardware, for which the file write sync operation can be done in userspace with low overhead and a high degree of parallelism. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3289) Allow LRA method execution when for closed LRA when the LRA is nested and the participant is already registered

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3289?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3289: ----------------------------------- Fix Version/s: 5.next > Allow LRA method execution when for closed LRA when the LRA is nested and the participant is already registered > --------------------------------------------------------------------------------------------------------------- > > Key: JBTM-3289 > URL: https://issues.redhat.com/browse/JBTM-3289 > 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 > > > See https://github.com/eclipse/microprofile-lra/issues/274 and https://github.com/eclipse/microprofile-lra/pull/276. > Depends on https://github.com/eclipse/microprofile-lra/pull/293. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3286) LRA coordinator isn't exposing OpenAPI definitions

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3286?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3286: ----------------------------------- Fix Version/s: 5.next > LRA coordinator isn't exposing OpenAPI definitions > -------------------------------------------------- > > Key: JBTM-3286 > URL: https://issues.redhat.com/browse/JBTM-3286 > 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 > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3284) TckRecoveryTests are failing

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3284?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3284: ----------------------------------- Fix Version/s: 5.next > TckRecoveryTests are failing > ---------------------------- > > Key: JBTM-3284 > URL: https://issues.redhat.com/browse/JBTM-3284 > 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 > > > TckRecoveryTests are failing with several issues. Also will require some fixes in the TCK. > {noformat} > [INFO] [lra-coordinator-it-test] Caused by: java.lang.NullPointerException > [INFO] [lra-coordinator-it-test] at io.narayana.lra.coordinator.domain.model.LRARecord.atEnd(LRARecord.java:443) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

1
0
0 / 0

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

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3293?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3293: ----------------------------------- Fix Version/s: 5.next > 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, 1 month

1
0
0 / 0

[JBoss JIRA] (JBTM-3294) Include a custom HTTP LRA version header on REST calls made by our implementation

by Michael Musgrove (Jira)

Michael Musgrove created JBTM-3294: -------------------------------------- Summary: Include a custom HTTP LRA version header on REST calls made by our implementation Key: JBTM-3294 URL: https://issues.redhat.com/browse/JBTM-3294 Project: JBoss Transaction Manager Issue Type: Enhancement Components: LRA Affects Versions: 5.10.4.Final Reporter: Michael Musgrove Assignee: Michael Musgrove Fix For: 5.next Our implementation of the LRA specification exposes REST endpoints whose semantics may change over time. As the LRA spec evolves users will need a guarantee that the endpoints behave consistently. To avoid introducing breaking changes I propose that we version REST API calls made by the implementation using a version header, something like: bq. OpenStack-API-Version: narayana LRA 5.10.5.Final or bq. OpenStack-API-Version: narayana LRA 5.10.5.Final https://<the location of our OpenAPI document> I went for the [OpenStack guideline|https://specs.openstack.org/openstack/api-wg/guidelines/headers...] since it was the only standard I could find for custom headers. A reason it is narayana specific is that our API offers more than the spec requires. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 1 month

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