May 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3315) RecoveryDriver should offer methods for verbose scan

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3315?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3315: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1622 > RecoveryDriver should offer methods for verbose scan > ---------------------------------------------------- > > Key: JBTM-3315 > URL: https://issues.redhat.com/browse/JBTM-3315 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: Recovery > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Minor > > It would be fine if the {{RecoveryDriver}} is enhanced with methods to scan verbosely. > https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... > Currently there are only methods {{synchronousScan}} and {{asynchronousScan}}. > The point is to add at least the two more {{synchronousVerboseScan}} and {{asynchronousVerboseScan}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3315) RecoveryDriver should offer methods for verbose scan

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3315: -------------------------------------- Summary: RecoveryDriver should offer methods for verbose scan Key: JBTM-3315 URL: https://issues.redhat.com/browse/JBTM-3315 Project: JBoss Transaction Manager Issue Type: Enhancement Components: Recovery Affects Versions: 5.10.4.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka It would be fine if the {{RecoveryDriver}} is enhanced with methods to scan verbosely. https://github.com/jbosstm/narayana/blob/5.10.4.Final/ArjunaCore/arjuna/c... Currently there are only methods {{synchronousScan}} and {{asynchronousScan}}. The point is to add at least the two more {{synchronousVerboseScan}} and {{asynchronousVerboseScan}}. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 11 months

1
0
0 / 0

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

by Sanne Grinovero (Jira)

[ https://issues.redhat.com/browse/JBTM-3273?page=com.atlassian.jira.plugin... ] Sanne Grinovero commented on JBTM-3273: --------------------------------------- Many thanks! Looking forward to the next release. > 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 > Fix For: 5.next > > > 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)

3 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3314) Create a Narayana quickstart showing REST-AT working with Spring Boot + JAX-RS

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3314?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3314: ----------------------------------- Summary: Create a Narayana quickstart showing REST-AT working with Spring Boot + JAX-RS (was: Create a Narayana quickstart showing REST-AT working with Spring Boot using JAX-RS) > Create a Narayana quickstart showing REST-AT working with Spring Boot + JAX-RS > ------------------------------------------------------------------------------ > > Key: JBTM-3314 > URL: https://issues.redhat.com/browse/JBTM-3314 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Quickstarts > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Priority: Major > > It would be good to have a showcase of how Narayana REST-AT works on Spring Boot. > The REST-AT is currently integrated only with JAX-RS (not with the Spring Boot WebFramework!, until JBTM-3288 is fixed). > So the showcase should be using the Spring Boot when the JAX-RS is used there. > Thus the quickstart would show the integration of Narayana REST-AT with Spring boot using the JAX-RS starter (https://github.com/resteasy/resteasy-spring-boot), probably then the whole pack deployed on WildFly (it depends on the implementor decision and the integration possibilities). -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3314) Create a Narayana quickstart showing REST-AT working with Spring Boot using JAX-RS

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3314?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka commented on JBTM-3314: ---------------------------------------- Integration of the JAX-RS resteasy with Spring Boot were in relation to Narayana used in PoC for LRA (https://github.com/mkralik3/lra-springboot-axon-quickstart). It's not what this quickstart should be about but I mention it here that that the integration of spring boot and jax-rs could work somehow fine. > Create a Narayana quickstart showing REST-AT working with Spring Boot using JAX-RS > ---------------------------------------------------------------------------------- > > Key: JBTM-3314 > URL: https://issues.redhat.com/browse/JBTM-3314 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Quickstarts > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Priority: Major > > It would be good to have a showcase of how Narayana REST-AT works on Spring Boot. > The REST-AT is currently integrated only with JAX-RS (not with the Spring Boot WebFramework!, until JBTM-3288 is fixed). > So the showcase should be using the Spring Boot when the JAX-RS is used there. > Thus the quickstart would show the integration of Narayana REST-AT with Spring boot using the JAX-RS starter (https://github.com/resteasy/resteasy-spring-boot), probably then the whole pack deployed on WildFly (it depends on the implementor decision and the integration possibilities). -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3314) Create a Narayana quickstart showing REST-AT working with Spring Boot using JAX-RS

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3314: -------------------------------------- Summary: Create a Narayana quickstart showing REST-AT working with Spring Boot using JAX-RS Key: JBTM-3314 URL: https://issues.redhat.com/browse/JBTM-3314 Project: JBoss Transaction Manager Issue Type: Task Components: Quickstarts Affects Versions: 5.10.4.Final Reporter: Ondrej Chaloupka It would be good to have a showcase of how Narayana REST-AT works on Spring Boot. The REST-AT is currently integrated only with JAX-RS (not with the Spring Boot WebFramework!, until JBTM-3288 is fixed). So the showcase should be using the Spring Boot when the JAX-RS is used there. Thus the quickstart would show the integration of Narayana REST-AT with Spring boot using the JAX-RS starter (https://github.com/resteasy/resteasy-spring-boot), probably then the whole pack deployed on WildFly (it depends on the implementor decision and the integration possibilities). -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3205) LRA Spring Boot + JAX-RS support

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3205?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3205: ----------------------------------- Summary: LRA Spring Boot + JAX-RS support (was: Spring Boot + JAX-RS support) > LRA Spring Boot + JAX-RS support > -------------------------------- > > Key: JBTM-3205 > URL: https://issues.redhat.com/browse/JBTM-3205 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Reporter: Matej Kralik > Assignee: Michael Musgrove > Priority: Major > > I created this enhancement for tracking all issues for Spring Boot + JAX-RS application. > {code:xml} > ... > <parent> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-starter-parent</artifactId> > <version>2.1.6.RELEASE</version> > <relativePath/>  > </parent> > ... > <dependencies> >  > <dependency> > <groupId>org.springframework.boot</groupId> > <artifactId>spring-boot-starter-jersey</artifactId> > </dependency> > ... > </dependencies> > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3215) Rethink the system of configuration and properties with narrowing the API

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3215?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka reassigned JBTM-3215: -------------------------------------- Assignee: Miloslav Žežulka > Rethink the system of configuration and properties with narrowing the API > ------------------------------------------------------------------------- > > Key: JBTM-3215 > URL: https://issues.redhat.com/browse/JBTM-3215 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Affects Versions: 5.9.8.Final > Reporter: Ondrej Chaloupka > Assignee: Miloslav Žežulka > Priority: Major > Fix For: 6.later > > > With the growth of integrations of Narayana into various runtime, it would be good to think about the appropriateness of the configuration of Narayana via different beans and usage of reflection. The use of the reflection is especially pain point for Quarkus runtime as it decreases the startup time significantly. > There is a quick fix for reflection usage as the issue JBTM-3214 and the discussion was run at the PR of the issue at https://github.com/jbosstm/narayana/pull/1521. > Narrowing the API: the JBTM-3214 opens the `BeanPopulator` class create the bean class during the startup. With this change comes a possible trouble if multiple libraries tries to define the class during the startup. The one which creates and executes the bean or first one which grabs the bean defines the configuration. The following code which would try to setup the configuration will not be able to do so. Only the first setter is considered. > Then possibly a single mechanism for configuration could be considered. For example we can have definition that says that all beans are for configuration from the XML (then reflection and xml parsing are done) or all beans are configurable with an external provider (no reflection and xml parsing). > The `BeanPopulator` would then not having any `setter` but only `getters` (as it was until JBTM-3214) and the global configuration property will configure if reflection and XML parsing will be used or not. > There is another point to consider. The Narayana configuration suffers with trouble of using `TxControl` class which is statically defined and when it's defined for the first time then change of configuration is harder. The developer needs to touch first the bean and as the second thing he needs to change the value owned by the `TxControl` class. -- This message was sent by Atlassian Jira (v7.13.8#713008)

3 years, 12 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3284?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3284: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > 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)

3 years, 12 months

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

3 years, 12 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 May 2020