January 2020 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3227) LRA branch TckTests#TestForget is failing on our CI infrastructure

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3227?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3227: ---------------------------------------- Can this be marked resolved yet (without fix version though) as it is on LRA branch: https://github.com/jbosstm/narayana/commits/LRA > LRA branch TckTests#TestForget is failing on our CI infrastructure > ------------------------------------------------------------------ > > Key: JBTM-3227 > URL: https://issues.redhat.com/browse/JBTM-3227 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA, Testing > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > > The LRA branch tracks MP-LRA changes and we test it on our CI set up. > The branch depends on snapshot builds but the current build is failing because the test TckTests#TestForget is wrong and it has been fixed in a later snapshot. Therefore we need to upgrade the snapshot build dependency -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3229) Allow to enlist AfterLRA listeners after the LRA enters the ending phase

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3229?page=com.atlassian.jira.plugin... ] Thomas Jenkinson edited comment on JBTM-3229 at 1/16/20 7:02 AM: ----------------------------------------------------------------- Can this be marked resolved yet (without fix version though) as it is on LRA branch: https://github.com/jbosstm/narayana/commits/LRA was (Author: tomjenkinson): Shouldn't this be marked resolved (without fix version though) as it is on LRA branch: https://github.com/jbosstm/narayana/commits/LRA > Allow to enlist AfterLRA listeners after the LRA enters the ending phase > ------------------------------------------------------------------------ > > Key: JBTM-3229 > URL: https://issues.redhat.com/browse/JBTM-3229 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > https://github.com/eclipse/microprofile-lra/issues/241 > The specification was updated to allow AfterLRA listeners (LRA resources without Compensate method but with the AfterLRA method) to enlist for AfterLRA notification even after the LRA enters the ending (closing/canceling) phase. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer)

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3243: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer) > ----------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@PreDestroy` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @PreDestroy > void disableRecovery() > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3242) Starting an LRA using a POST request does not set the HTTP Location header

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3242?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3242: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > Starting an LRA using a POST request does not set the HTTP Location header > -------------------------------------------------------------------------- > > Key: JBTM-3242 > URL: https://issues.redhat.com/browse/JBTM-3242 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > LRA's are created by sending an HTTP POST request to the coordinator. POST requests that create new resources normally return the newly created resource in the Location header [1] or based on the "effective request URI" [2]. > The coordinator implementation does not set the Location header. > [1] https://tools.ietf.org/html/rfc7231#section-6.3.2 > [2] https://tools.ietf.org/html/rfc7230#section-5.5 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer)

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Michael Musgrove commented on JBTM-3243: ---------------------------------------- I went with @PreDestroy (and @PostConstruct) instead. Remark: The recovery system just needs to be started at some point (but it should happen as early as possibly before we start processing LRAs) so @PostConstruct is sufficient for the needs of LRA. > Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer) > ----------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@PreDestroy` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @PreDestroy > void disableRecovery() > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer)

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3243: ----------------------------------- Summary: Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer) (was: Observer method for ApplicationScoped bean destruction creates a new bean) > Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer) > ----------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @ActivateRequestContext > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) { > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer)

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3243: ----------------------------------- Description: The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@PreDestroy` will ensure the correct application scoped bean used. So instead of {code} void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) {code} use {code} @PreDestroy void disableRecovery() {code} was: The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of {code} void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) {code} use {code} @ActivateRequestContext void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) { {code} > Use PostConstruct/PreDestroy for ApplicationScoped bean (instead of Observer) > ----------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@PreDestroy` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @PreDestroy > void disableRecovery() > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3242) Starting an LRA using a POST request does not set the HTTP Location header

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3242?page=com.atlassian.jira.plugin... ] Michael Musgrove updated JBTM-3242: ----------------------------------- Issue Type: Enhancement (was: Bug) > Starting an LRA using a POST request does not set the HTTP Location header > -------------------------------------------------------------------------- > > Key: JBTM-3242 > URL: https://issues.redhat.com/browse/JBTM-3242 > Project: JBoss Transaction Manager > Issue Type: Enhancement > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > LRA's are created by sending an HTTP POST request to the coordinator. POST requests that create new resources normally return the newly created resource in the Location header [1] or based on the "effective request URI" [2]. > The coordinator implementation does not set the Location header. > [1] https://tools.ietf.org/html/rfc7231#section-6.3.2 > [2] https://tools.ietf.org/html/rfc7230#section-5.5 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3243) Observer method for ApplicationScoped bean destruction creates a new bean

by Thomas Jenkinson (Jira)

[ https://issues.redhat.com/browse/JBTM-3243?page=com.atlassian.jira.plugin... ] Thomas Jenkinson commented on JBTM-3243: ---------------------------------------- Given that https://jakarta.ee/specifications/platform/8/apidocs/javax/enterprise/con... seems like it might also create a new bean (perhaps request scoped?), I am wondering if this hints there is actually a problem with the way the LRAService is set up to observe these events in general. I think https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... would be expected to use the init param in it's initialization routine. But I also think that in order to do so we should be checking that the bean that has been initialized is actually an LRAService and not just any application scoped bean. Unless I am misunderstanding CDI and the code I don't think just any applicationscoped bean being initialized would prevent this method from firing. But I do wonder if we might be able to use https://jakarta.ee/specifications/platform/8/apidocs/javax/annotation/Pos... instead of looking for the initialized event? Especially given until the https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... call is executed I don't think LRA would really be considered fully initialized and so perhaps race conditions could occur where the recordtypemanager was not correctly set up? Regarding the destruction handling, does it definitely have to be after LRAService is destroyed? Perhaps the recovery module could be unloaded during a https://jakarta.ee/specifications/platform/8/apidocs/javax/annotation/Pre... on LRAService instead? I note https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator-j... seems to be a no-op - I would wonder why https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes... is not called, but then PreDestroy might be too early and perhaps in that case a separate RequestScoped bean will need to be added to observe the LRAService being destroyed and perform these steps. > Observer method for ApplicationScoped bean destruction creates a new bean > ------------------------------------------------------------------------- > > Key: JBTM-3243 > URL: https://issues.redhat.com/browse/JBTM-3243 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The LRA implementation needs to observe application shutdown in order to perform clean up activities. It achieves this using an ApplicationScoped bean. But when the destroyed event is fired a new bean may be created which is not what we want with an application scoped bean (this behaviour is seen when running as a Quarkus app). Annotating the method with `@ActivateRequestContext` will ensure the correct application scoped bean used. So instead of > {code} > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) > {code} > use > {code} > @ActivateRequestContext > void disableRecovery(@Observes @Destroyed(ApplicationScoped.class) Object ignore) { > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3242) Starting an LRA using a POST request does not set the HTTP Location header

by Michael Musgrove (Jira)

[ https://issues.redhat.com/browse/JBTM-3242?page=com.atlassian.jira.plugin... ] Issue was automatically transitioned when Michael Musgrove created pull request #1546 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > Starting an LRA using a POST request does not set the HTTP Location header > -------------------------------------------------------------------------- > > Key: JBTM-3242 > URL: https://issues.redhat.com/browse/JBTM-3242 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.10.1.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > LRA's are created by sending an HTTP POST request to the coordinator. POST requests that create new resources normally return the newly created resource in the Location header [1] or based on the "effective request URI" [2]. > The coordinator implementation does not set the Location header. > [1] https://tools.ietf.org/html/rfc7231#section-6.3.2 > [2] https://tools.ietf.org/html/rfc7230#section-5.5 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 3 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 January 2020