May 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3321) The REST-AT inbound bridge provider wrongly uses the customer priority

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3321?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3321: ----------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1628 > The REST-AT inbound bridge provider wrongly uses the customer priority > ---------------------------------------------------------------------- > > Key: JBTM-3321 > URL: https://issues.redhat.com/browse/JBTM-3321 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: REST > Affects Versions: 5.10.4.Final > Reporter: Ondrej Chaloupka > Assignee: Ondrej Chaloupka > Priority: Major > > The current REST-AT inbound bridge wrongly uses the user {{@Priority}} value (https://docs.oracle.com/javaee/7/api/javax/ws/rs/Priorities.html#USER). > The transactional interceptor should not be called at the same time as the user interceptors and it has to go before them. > This is a not expected ordering and it may cause issues when a user adds his own provider. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3321) The REST-AT inbound bridge provider wrongly uses the customer priority

by Ondrej Chaloupka (Jira)

Ondrej Chaloupka created JBTM-3321: -------------------------------------- Summary: The REST-AT inbound bridge provider wrongly uses the customer priority Key: JBTM-3321 URL: https://issues.redhat.com/browse/JBTM-3321 Project: JBoss Transaction Manager Issue Type: Bug Components: REST Affects Versions: 5.10.4.Final Reporter: Ondrej Chaloupka Assignee: Ondrej Chaloupka The current REST-AT inbound bridge wrongly uses the user {{@Priority}} value (https://docs.oracle.com/javaee/7/api/javax/ws/rs/Priorities.html#USER). The transactional interceptor should not be called at the same time as the user interceptors and it has to go before them. This is a not expected ordering and it may cause issues when a user adds his own provider. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3320) LRA forget calls for nested completed participants are not repeated and do not close the LRA

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3320?page=com.atlassian.jira.plugin... ] Martin Stefanko updated JBTM-3320: ---------------------------------- Status: Pull Request Sent (was: Open) Git Pull Request: https://github.com/jbosstm/narayana/pull/1626 > LRA forget calls for nested completed participants are not repeated and do not close the LRA > -------------------------------------------------------------------------------------------- > > Key: JBTM-3320 > URL: https://issues.redhat.com/browse/JBTM-3320 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > forgetAllParticipants does not repeat failed forget calls and if the calls are successful the nested LRA is not finished. This leaves the nested LRA active. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3308) Some TCK tests pass but leave the LRAs in not finished state

by Martin Stefanko (Jira)

[ https://issues.redhat.com/browse/JBTM-3308?page=com.atlassian.jira.plugin... ] Martin Stefanko edited comment on JBTM-3308 at 5/21/20 4:48 AM: ---------------------------------------------------------------- I don't see the way how to link different JBTMs. I will keep the list of forked issues in this comment: * https://issues.redhat.com/browse/JBTM-3312 * https://issues.redhat.com/browse/JBTM-3320 was (Author: mstefank): I don't see the way how to link different JBTMs. I will keep the list of forked issues in this comment: * https://issues.redhat.com/browse/JBTM-3312 > Some TCK tests pass but leave the LRAs in not finished state > ------------------------------------------------------------ > > Key: JBTM-3308 > URL: https://issues.redhat.com/browse/JBTM-3308 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.4.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > It seems that the LRA is correctly closed but the /lra-coordinator still reports it in Active status. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3320) LRA forget calls for nested completed participants are not repeated and do not close the LRA

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3320: ------------------------------------- Summary: LRA forget calls for nested completed participants are not repeated and do not close the LRA Key: JBTM-3320 URL: https://issues.redhat.com/browse/JBTM-3320 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.10.5.Final Reporter: Martin Stefanko Assignee: Martin Stefanko forgetAllParticipants does not repeat failed forget calls and if the calls are successful the nested LRA is not finished. This leaves the nested LRA active. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3294?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3294 at 5/20/20 10:08 AM: ------------------------------------------------------------------ We've discussed the aspects of the REST api versioning related to LRA concept within the team. For the version will be used a custom header with version in format {{<major>.<minor>}}. Where we expect for a breaking change having a new {{<major>}} version. {{<minor>}} version is to be used for addition and other API changes which does not make compatibility issue. There should be supported at least three versions (the new and the old ones) of API in parallel. The api will be documented with Swagger/OpenAPI (as it already is) and we should find a proper place where to place the API description (probably at http://narayana.io) was (Author: ochaloup): We've discussed the aspects of the REST api versioning related to LRA concept in the team. For the version will be used a custom header with version in format {{<major>.<minor>}}. Where we expect for a breaking change having a new {{<major>}} version. {{<minor>}} version is to be used for addition and other API changes which does not make compatibility issue. There should be supported at least three versions (the new and the old ones) of API in parallel. The api will be documented with Swagger/OpenAPI (as it already is) and we should find a proper place where to place the API description (probably at http://narayana.io) > 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: Ondrej Chaloupka > Priority: Blocker > > 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, 6 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3294?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka edited comment on JBTM-3294 at 5/20/20 10:08 AM: ------------------------------------------------------------------ We've discussed the aspects of the REST api versioning related to LRA concept in the team. For the version will be used a custom header with version in format {{<major>.<minor>}}. Where we expect for a breaking change having a new {{<major>}} version. {{<minor>}} version is to be used for addition and other API changes which does not make compatibility issue. There should be supported at least three versions (the new and the old ones) of API in parallel. The api will be documented with Swagger/OpenAPI (as it already is) and we should find a proper place where to place the API description (probably at http://narayana.io) > 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: Ondrej Chaloupka > Priority: Blocker > > 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, 6 months

1
0
0 / 0

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

by Ondrej Chaloupka (Jira)

[ https://issues.redhat.com/browse/JBTM-3294?page=com.atlassian.jira.plugin... ] Ondrej Chaloupka updated JBTM-3294: ----------------------------------- Forum Reference: https://groups.google.com/forum/#!topic/narayana-users/YIsqDp38Sb8 > 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: Ondrej Chaloupka > Priority: Blocker > > 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, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Thomas Jenkinson closed JBTM-3260. ---------------------------------- Resolution: Migrated to another ITS > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3260) On publishing a new Narayana release there should be created Quarkus PR to update Narayana version

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3260?page=com.atlassian.jira.plugin... ] Thomas Jenkinson updated JBTM-3260: ----------------------------------- Fix Version/s: (was: 5.10.5.Final) > On publishing a new Narayana release there should be created Quarkus PR to update Narayana version > -------------------------------------------------------------------------------------------------- > > Key: JBTM-3260 > URL: https://issues.redhat.com/browse/JBTM-3260 > Project: JBoss Transaction Manager > Issue Type: Task > Components: Release Process > Affects Versions: 5.10.3.Final > Reporter: Ondrej Chaloupka > Assignee: Mayank Kunwar > Priority: Major > > As currently when a Narayana minor release is published it's usual to create a WildFly pull request which updates the Narayana version to the most up-to-date. > This functionality is automatized in the release script: > https://github.com/jbosstm/narayana/blob/5.10.4.Final/narayana-release-pr... > It would be good to have a similar functionality for the Quarkus. Narayana is the component managing JTA trasaction there and it would be good to pass there the newest version as well. > Narayana version could be updated at: > https://github.com/quarkusio/quarkus/blob/1.2.1.Final/bom/runtime/pom.xml... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 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