June 2019 - jbossts-issues - Jboss List Archives

[JBoss JIRA] (JBTM-3158) jta-and-hibernate-standalone Narayana quickstart will not execute properly - EntityExistsException

by Miloslav Žežulka (Jira)

Miloslav Žežulka created JBTM-3158: -------------------------------------- Summary: jta-and-hibernate-standalone Narayana quickstart will not execute properly - EntityExistsException Key: JBTM-3158 URL: https://issues.jboss.org/browse/JBTM-3158 Project: JBoss Transaction Manager Issue Type: Bug Components: Testing Reporter: Miloslav Žežulka Assignee: Ondrej Chaloupka One of the [Narayana quickstarts|https://github.com/jbosstm/quickstart] throws the following exception when executed according to the steps in README.md: java.lang.reflect.InvocationTargetException 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.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:293) at java.lang.Thread.run (Thread.java:748) Caused by: javax.persistence.EntityExistsException: A different object with the same identifier value was already associated with the session : [org.jboss.narayana.quickstart.jta.QuickstartEntity#1] at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1664) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1602) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.convert (AbstractEntityManagerImpl.java:1608) at org.hibernate.jpa.spi.AbstractEntityManagerImpl.persist (AbstractEntityManagerImpl.java:1152) at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository.save (QuickstartEntityRepository.java:45) at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository$Proxy$_$$_WeldSubclass.save$$super (Unknown Source) 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.jboss.weld.interceptor.proxy.TerminalAroundInvokeInvocationContext.proceedInternal (TerminalAroundInvokeInvocationContext.java:49) at org.jboss.weld.interceptor.proxy.AroundInvokeInvocationContext.proceed (AroundInvokeInvocationContext.java:77) at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.invokeInCallerTx (TransactionalInterceptorBase.java:186) at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.doIntercept (TransactionalInterceptorRequired.java:55) at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorBase.intercept (TransactionalInterceptorBase.java:88) at com.arjuna.ats.jta.cdi.transactional.TransactionalInterceptorRequired.intercept (TransactionalInterceptorRequired.java:47) 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.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke (SimpleInterceptorInvocation.java:74) at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeAroundInvoke (InterceptorMethodHandler.java:84) at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.executeInterception (InterceptorMethodHandler.java:72) at org.jboss.weld.interceptor.proxy.InterceptorMethodHandler.invoke (InterceptorMethodHandler.java:56) at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke (CombinedInterceptorAndDecoratorStackMethodHandler.java:79) at org.jboss.weld.bean.proxy.CombinedInterceptorAndDecoratorStackMethodHandler.invoke (CombinedInterceptorAndDecoratorStackMethodHandler.java:68) at org.jboss.narayana.quickstart.jta.QuickstartEntityRepository$Proxy$_$$_WeldSubclass.save (Unknown Source) at org.jboss.narayana.quickstart.jta.QuickstartService.executeDemonstration (QuickstartService.java:106) at org.jboss.narayana.quickstart.jta.QuickstartService.demonstrateCommit (QuickstartService.java:55) at org.jboss.narayana.quickstart.jta.QuickstartApplication.main (QuickstartApplication.java:78) 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.mojo.exec.ExecJavaMojo$1.run (ExecJavaMojo.java:293) at java.lang.Thread.run (Thread.java:748) -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3157) LRA participant does not respect JAX-RS path definitions

by Anonymous (Jira)

[ https://issues.jboss.org/browse/JBTM-3157?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Martin Stefanko created pull request #1462 in GitHub ---------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Open) > LRA participant does not respect JAX-RS path definitions > -------------------------------------------------------- > > Key: JBTM-3157 > URL: https://issues.jboss.org/browse/JBTM-3157 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > When LRA participant defines paths for participant methods like this: > {code:java} > @PUT > @Path("compensate") > @Compensate > public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > instead of: > {code:java} > @PUT > @Path("/compensate") > @Compensate > public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { > System.out.println("Compensate: " + lraId); > } > {code} > The participant methods are never executed because the constructed URL is not valid. However, even the first code snippet is still a valid JAX-RS resource definition and thus it should be respected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3157) LRA participant does not respect JAX-RS path definitions

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3157: ------------------------------------- Summary: LRA participant does not respect JAX-RS path definitions Key: JBTM-3157 URL: https://issues.jboss.org/browse/JBTM-3157 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Martin Stefanko Assignee: Martin Stefanko When LRA participant defines paths for participant methods like this: {code:java} @PUT @Path("compensate") @Compensate public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { System.out.println("Compensate: " + lraId); } {code} instead of: {code:java} @PUT @Path("/compensate") @Compensate public void compensate((a)HeaderParam(LRA.LRA_HTTP_CONTEXT_HEADER) URI lraId) { System.out.println("Compensate: " + lraId); } {code} The participant methods are never executed because the constructed URL is not valid. However, even the first code snippet is still a valid JAX-RS resource definition and thus it should be respected. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3145: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA TCK test failure on CI > -------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Issue was automatically transitioned when Michael Musgrove created pull request #1461 in GitHub ----------------------------------------------------------------------------------------------- Status: Pull Request Sent (was: Reopened) > LRA TCK test failure on CI > -------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Michael Musgrove reopened JBTM-3145: ------------------------------------ TckTest#timeLimit is still failing > LRA TCK test failure on CI > -------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3145) LRA TCK test failure on CI

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3145?page=com.atlassian.jira.plugin.... ] Michael Musgrove updated JBTM-3145: ----------------------------------- Status: Resolved (was: Pull Request Sent) Resolution: Done > LRA TCK test failure on CI > -------------------------- > > Key: JBTM-3145 > URL: https://issues.jboss.org/browse/JBTM-3145 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Michael Musgrove > Assignee: Michael Musgrove > Priority: Major > Fix For: 5.next > > > The test TckTests#timeLimit fails every time on the JDK 11 CI run (but not on JDK 8). For example > http://narayanaci1.eng.hst.ams2.redhat.com/job/narayana/426/PROFILE=LRA,j... > It is also failing consistently on JDK8 (after the the migration to thorntail) with: > [INFO] [lra-coordinator-it-test] 2019-06-06 20:19:46,751 WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (ForkJoinPool.commonPool-worker-26) RESTEASY002120: ClassNotFoundException: Unable to load builtin provider org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider from jar:file:/tmp/thorntailresteasy-jaxb-provider-3.6.2.Final3540226414131235050.jar!/META-INF/services/javax.ws.rs.ext.Providers: java.lang.ClassNotFoundException: org.jboss.resteasy.plugins.providers.jaxb.JAXBXmlSeeAlsoProvider -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3156) LRA does not respect all participant immediate state indications

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3156?page=com.atlassian.jira.plugin.... ] Michael Musgrove closed JBTM-3156. ---------------------------------- Release Notes Text: The coordinator is a REST resource and it expects compensators to return 202 Accepted if the resource update is still in progress. Resolution: Rejected > LRA does not respect all participant immediate state indications > ---------------------------------------------------------------- > > Key: JBTM-3156 > URL: https://issues.jboss.org/browse/JBTM-3156 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The specification states at https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asc...: > {noformat} > If the resource cannot perform a compensation activity immediately the @Compensate method SHOULD do one or more of the following: > return ParticipantStatus.Compensating > return a 202 Accepted HTTP status code > mark the method as a JAX-RS asynchronous method (using the javax.ws.rs.container.Suspended annotation). > {noformat} > However, Narayana respects only the ACCEPTED status code: https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/s... > The implementation should also cover two other variants. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3156) LRA does not respect all participant immediate state indications

by Michael Musgrove (Jira)

[ https://issues.jboss.org/browse/JBTM-3156?page=com.atlassian.jira.plugin.... ] Michael Musgrove commented on JBTM-3156: ---------------------------------------- The coordinator is a REST resource and it expects a compensator to return 202 Accepted if the resource update is still in progress. I would clarify the spec to state that JAX-RS based compensators MUST return 202 if they cannot perform compensation actions immediately. I will raise a PR on MP-LRA to provide the clarification. > LRA does not respect all participant immediate state indications > ---------------------------------------------------------------- > > Key: JBTM-3156 > URL: https://issues.jboss.org/browse/JBTM-3156 > Project: JBoss Transaction Manager > Issue Type: Bug > Components: LRA > Affects Versions: 5.9.5.Final > Reporter: Martin Stefanko > Assignee: Martin Stefanko > Priority: Major > > The specification states at https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asc...: > {noformat} > If the resource cannot perform a compensation activity immediately the @Compensate method SHOULD do one or more of the following: > return ParticipantStatus.Compensating > return a 202 Accepted HTTP status code > mark the method as a JAX-RS asynchronous method (using the javax.ws.rs.container.Suspended annotation). > {noformat} > However, Narayana respects only the ACCEPTED status code: https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/s... > The implementation should also cover two other variants. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 months

1
0
0 / 0

[JBoss JIRA] (JBTM-3156) LRA does not respect all participant immediate state indications

by Martin Stefanko (Jira)

Martin Stefanko created JBTM-3156: ------------------------------------- Summary: LRA does not respect all participant immediate state indications Key: JBTM-3156 URL: https://issues.jboss.org/browse/JBTM-3156 Project: JBoss Transaction Manager Issue Type: Bug Components: LRA Affects Versions: 5.9.5.Final Reporter: Martin Stefanko Assignee: Martin Stefanko The specification states at https://github.com/eclipse/microprofile-lra/blob/master/spec/src/main/asc...: {noformat} If the resource cannot perform a compensation activity immediately the @Compensate method SHOULD do one or more of the following: return ParticipantStatus.Compensating return a 202 Accepted HTTP status code mark the method as a JAX-RS asynchronous method (using the javax.ws.rs.container.Suspended annotation). {noformat} However, Narayana respects only the ACCEPTED status code: https://github.com/jbosstm/narayana/blob/master/rts/lra/lra-coordinator/s... The implementation should also cover two other variants. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 5 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 June 2019