[JBoss JIRA] (JBTM-2944) LRA specification updates
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2944:
-----------------------------------
Status: Resolved (was: Pull Request Sent)
Resolution: Done
> LRA specification updates
> -------------------------
>
> Key: JBTM-2944
> URL: https://issues.jboss.org/browse/JBTM-2944
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.7.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
> 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
> 2. Terminating an LRA MAY return the status of the LRA.
> 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
> 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
>
> 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
> 6. Remove the interface method for starting an LRA
> {code}
> URL startLRA(String clientID, Long timeout) throws GenericLRAException;
> {code}
> since it is superfluous - just use the one that takes a timeunit instead:
> {code}
> URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2944) LRA specification updates
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2944:
-----------------------------------
Description:
The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
2. Terminating an LRA MAY return the status of the LRA.
3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
6. Remove the interface method for starting an LRA
{code}
URL startLRA(String clientID, Long timeout) throws GenericLRAException;
{code}
since it is superfluous - just use the one that takes a timeunit instead:
{code}
URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
{code}
was:
The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
5. Remove the interface method for starting an LRA
{code}
URL startLRA(String clientID, Long timeout) throws GenericLRAException;
{code}
since it is superfluous - just use the one that takes a timeunit instead:
{code}
URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
{code}
> LRA specification updates
> -------------------------
>
> Key: JBTM-2944
> URL: https://issues.jboss.org/browse/JBTM-2944
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.7.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
> 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
> 2. Terminating an LRA MAY return the status of the LRA.
> 3. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
> 4 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
>
> 5. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
> 6. Remove the interface method for starting an LRA
> {code}
> URL startLRA(String clientID, Long timeout) throws GenericLRAException;
> {code}
> since it is superfluous - just use the one that takes a timeunit instead:
> {code}
> URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2944) LRA specification updates
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.... ]
Issue was automatically transitioned when Michael Musgrove created pull request #1231 in GitHub
-----------------------------------------------------------------------------------------------
Status: Pull Request Sent (was: Open)
> LRA specification updates
> -------------------------
>
> Key: JBTM-2944
> URL: https://issues.jboss.org/browse/JBTM-2944
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.7.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
> 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
> 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
> 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
>
> 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
> 5. Remove the interface method for starting an LRA
> {code}
> URL startLRA(String clientID, Long timeout) throws GenericLRAException;
> {code}
> since it is superfluous - just use the one that takes a timeunit instead:
> {code}
> URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2944) LRA specification updates
by Michael Musgrove (JIRA)
[ https://issues.jboss.org/browse/JBTM-2944?page=com.atlassian.jira.plugin.... ]
Michael Musgrove updated JBTM-2944:
-----------------------------------
Summary: LRA specification updates (was: More specification updates)
> LRA specification updates
> -------------------------
>
> Key: JBTM-2944
> URL: https://issues.jboss.org/browse/JBTM-2944
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.7.0.Final
> Reporter: Michael Musgrove
> Assignee: Michael Musgrove
> Fix For: 5.next
>
>
> The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
> 1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
> 2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
> 3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
>
> 4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
> 5. Remove the interface method for starting an LRA
> {code}
> URL startLRA(String clientID, Long timeout) throws GenericLRAException;
> {code}
> since it is superfluous - just use the one that takes a timeunit instead:
> {code}
> URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2944) More specification updates
by Michael Musgrove (JIRA)
Michael Musgrove created JBTM-2944:
--------------------------------------
Summary: More specification updates
Key: JBTM-2944
URL: https://issues.jboss.org/browse/JBTM-2944
Project: JBoss Transaction Manager
Issue Type: Bug
Components: LRA
Affects Versions: 5.7.0.Final
Reporter: Michael Musgrove
Assignee: Michael Musgrove
Fix For: 5.next
The reference implementation needs synchronising with some recent spec changes (NB I will link the spec change PR shortly over in the sandbox https://github.com/jbosstm/microprofile-sandbox):
1. Allow the "pure java registration mechanism" (aka LRAManagement.java) to support asynchronous processing: i.e. make the completion methods return Future<Void> and monitor the future to report the status, hence we can remove the status() and forget() methods from the LRAParticipant.java interface thus making it much easier for developers to write LRA participants.
2. Ensure that if a termination method (complete/compensate) returns FailedToComplete or FailedToCompensate then we log it and ignore this participant on future recovery passes.
3 The query URLs are not RESTful. There are separate ones for asking for the LRAs in a particular state. The RESTful way is to provide a single endpoint which when combined with a query parameter will return just those LRAs that the client is interested in.
4. There are separate URLs for querying the different states of an LRA. A more RESTful way is a single GET url which reports the status in the response body.
5. Remove the interface method for starting an LRA
{code}
URL startLRA(String clientID, Long timeout) throws GenericLRAException;
{code}
since it is superfluous - just use the one that takes a timeunit instead:
{code}
URL startLRA(String clientID, Long timeout, TimeUnit unit) throws GenericLRAException;
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2932) LRA Cdi REST integration test hang
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2932?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-2932:
---------------------------------------
hi [~mmusgrov], I would like just check with you if this is still an issue? I wasn't able to simulate this on my machine and haven't seen it on CI either. Thanks.
> LRA Cdi REST integration test hang
> ----------------------------------
>
> Key: JBTM-2932
> URL: https://issues.jboss.org/browse/JBTM-2932
> Project: JBoss Transaction Manager
> Issue Type: Bug
> Components: LRA
> Affects Versions: 5.6.4.Final
> Reporter: Michael Musgrove
> Assignee: Ondra Chaloupka
>
> The test is hanging. Swarm boots fine but it then just waits (forever):
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
> Running io.narayana.lra.cdi.StartCdiCheckIT
> Tue Sep 19 10:29:53 BST 2017 INFO [org.wildfly.swarm.bootstrap] (main) Dependencies not bundled; resolving from M2REPO.
> [0m2017-09-19 10:29:55,627 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1
> [0m[0m2017-09-19 10:29:55,676 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1
> [0m[0m2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1
> [0m[0m2017-09-19 10:29:55,677 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1
> [0m[0m2017-09-19 10:29:55,678 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1
> [0m[0m2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1
> [0m[0m2017-09-19 10:29:55,679 INFO [org.wildfly.swarm] (main) WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1
> [0m[0m2017-09-19 10:29:59,617 INFO [org.jboss.msc] (main) JBoss MSC version 1.2.6.Final
> [0m[0m2017-09-19 10:29:59,729 INFO [org.jboss.as] (MSC service thread 1-1) WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting
> [0m[0m2017-09-19 10:29:59,822 INFO [org.wildfly.swarm] (MSC service thread 1-1) WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit5805521710512368243/junit2910476790071070383.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]]
> [0mCUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final
> CUSTOM LOG FORMAT INFO [org.xnio] XNIO version 3.4.3.Final
> CUSTOM LOG FORMAT INFO [org.xnio.nio] XNIO NIO Implementation Version 3.4.3.Final
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server.
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 3573ms - Started 88 of 97 services (18 services are lazy, passive or on-demand)
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war
> CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war")
> CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice.
> CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war
> CUSTOM LOG FORMAT INFO [org.hibernate.validator.internal.util.Version] HV000001: Hibernate Validator 5.2.4.Final
> CUSTOM LOG FORMAT INFO [org.jboss.weld.Version] WELD-000900: 2.3.5 (Final)
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting
> CUSTOM LOG FORMAT INFO [org.jboss.resteasy.resteasy_jaxrs.i18n] RESTEASY002225: Deploying javax.ws.rs.core.Application: class org.wildfly.swarm.generated.WildFlySwarmDefaultJAXRSApplication$Proxy$_$$_WeldClientProxy
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0021: Registered web context: /
> CUSTOM LOG FORMAT INFO [org.jboss.as.server] WFLYSRV0010: Deployed "lra-cdi-check.war" (runtime-name : "lra-cdi-check.war")
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0022: Unregistered web context: /
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping
> CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 88ms
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 94ms
> CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit411563760007331862/junit474695456187414375.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]]
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server.
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 264ms - Started 88 of 97 services (18 services are lazy, passive or on-demand)
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm.runtime.deployer] deploying lra-cdi-check.war
> CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0027: Starting deployment of "lra-cdi-check.war" (runtime-name: "lra-cdi-check.war")
> CUSTOM LOG FORMAT WARN [org.jboss.as.dependency.private] WFLYSRV0018: Deployment "deployment.lra-cdi-check.war" is using a private module ("org.jboss.jts:main") which may be changed or removed in future versions without notice.
> CUSTOM LOG FORMAT INFO [org.jboss.weld.deployer] WFLYWELD0003: Processing weld deployment lra-cdi-check.war
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0018: Host default-host starting
> CUSTOM LOG FORMAT ERROR [org.jboss.msc.service.fail] MSC000001: Failed to start service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."lra-cdi-check.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path
> at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128)
> 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:497)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:204)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> ... 3 more
> CUSTOM LOG FORMAT ERROR [org.jboss.as.controller.management-operation] WFLYCTL0013: Operation ("add") failed - address: (("deployment" => "lra-cdi-check.war")) - failure description: {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path
> at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128)
> 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:497)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> CUSTOM LOG FORMAT ERROR [org.jboss.as.server] WFLYSRV0021: Deploy of deployment "lra-cdi-check.war" was rolled back with the following failure message:
> {
> "WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> javax.enterprise.inject.spi.DeploymentException: Method 'compensate' of class 'io.narayana.lra.cdi.bean.AllAnnotationsNoPathBean' annotated by 'io.narayana.lra.annotation.Compensate' should use complementary annotation javax.ws.rs.Path
> at io.narayana.lra.cdi.LraAnnotationProcessingExtension.processLraAnnotatedType(LraAnnotationProcessingExtension.java:128)
> 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:497)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
> at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:125)
> at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
> at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:197)
> at org.jboss.weld.bootstrap.events.ContainerLifecycleEvents.fireProcessAnnotatedType(ContainerLifecycleEvents.java:169)
> at org.jboss.weld.bootstrap.BeanDeployer.processAnnotatedTypes(BeanDeployer.java:159)
> at org.jboss.weld.bootstrap.BeanDeployment.createTypes(BeanDeployment.java:224)
> at org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:383)
> at org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:94)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> "},
> "WFLYCTL0412: Required services that are not installed:" => ["jboss.deployment.unit.\"lra-cdi-check.war\".WeldStartService"],
> "WFLYCTL0180: Services with missing/unavailable dependencies" => undefined
> }
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0019: Host default-host stopping
> CUSTOM LOG FORMAT INFO [org.jboss.as.server.deployment] WFLYSRV0028: Stopped deployment lra-cdi-check.war (runtime-name: lra-cdi-check.war) in 26ms
> CUSTOM LOG FORMAT INFO [org.jboss.as.controller] WFLYCTL0183: Service status report
> WFLYCTL0184: New missing/unsatisfied dependencies:
> service jboss.deployment.unit."lra-cdi-check.war".WeldBootstrapService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator, WFLYCTL0208: ... and 2 more ]
> service jboss.deployment.unit."lra-cdi-check.war".WeldStartService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator, service jboss.undertow.deployment.default-server.default-host./, service jboss.deployment.unit."lra-cdi-check.war".CdiValidatorFactoryService, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, WFLYCTL0208: ... and 4 more ]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService]
> service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".CREATE (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./, service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService, service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService]
> service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".WeldInstantiator (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START]
> service jboss.deployment.unit."lra-cdi-check.war".ee.ComponentRegistry (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService]
> service jboss.deployment.unit."lra-cdi-check.war".jndiDependencyService (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldInitialListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."org.jboss.weld.servlet.WeldTerminalListener".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.PermittedTaglibsTLV".START, service jboss.deployment.unit."lra-cdi-check.war".component."javax.servlet.jsp.jstl.tlv.ScriptFreeTLV".START]
> service jboss.undertow.deployment.default-server.default-host./ (missing) dependents: [service jboss.deployment.unit."lra-cdi-check.war".deploymentCompleteService]
> service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./]
> service jboss.undertow.deployment.default-server.default-host./.codec (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService]
> service jboss.undertow.deployment.default-server.default-host./.session (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService]
> service org.wildfly.request-controller.control-point."lra-cdi-check.war".undertow (missing) dependents: [service jboss.undertow.deployment.default-server.default-host./.UndertowDeploymentInfoService]
> WFLYCTL0186: Services which failed to start: service jboss.deployment.unit."lra-cdi-check.war".WeldStartService
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0008: Undertow HTTP listener default suspending
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0007: Undertow HTTP listener default stopped, was bound to [0:0:0:0:0:0:0:0]:8080
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0004: Undertow 1.4.11.Final stopping
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0050: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) stopped in 18ms
> CUSTOM LOG FORMAT INFO [org.jboss.weld.Bootstrap] WELD-ENV-002001: Weld SE container internal shut down
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Logging - STABLE org.wildfly.swarm:logging:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Bean Validation - STABLE org.wildfly.swarm:bean-validation:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI Configuration - STABLE org.wildfly.swarm:cdi-config:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Transactions - STABLE org.wildfly.swarm:transactions:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: CDI - STABLE org.wildfly.swarm:cdi:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: Undertow - STABLE org.wildfly.swarm:undertow:2017.8.1
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0013: Installed fraction: JAX-RS - STABLE org.wildfly.swarm:jaxrs:2017.8.1
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0049: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) starting
> CUSTOM LOG FORMAT INFO [org.wildfly.swarm] WFSWARM0019: Install MSC service for command line args: [-Dswarm.logging.periodic-rotating-file-handlers=FILE, -Dswarm.logging.periodic-rotating-file-handlers.FILE.file.path=/var/folders/jm/mpp4zrfn3hx0lmc1jzvx1_s80000gr/T/junit4960954178688397094/junit1077340550039272742.tmp, -Dswarm.logging.root-logger.handlers=[CONSOLE,FILE]]
> CUSTOM LOG FORMAT WARN [org.jboss.as.txn] WFLYTX0013: Node identifier property is set to the default value. Please make sure it is unique.
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.io] WFLYIO001: Worker 'default' has auto-configured to 4 core threads with 32 task threads based on your 2 available processors
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0002: Activating Security Subsystem
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0003: Undertow 1.4.11.Final starting
> CUSTOM LOG FORMAT INFO [org.jboss.as.security] WFLYSEC0001: Current PicketBox version=4.9.6.Final
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0001: Activating Naming Subsystem
> CUSTOM LOG FORMAT INFO [org.jboss.as.naming] WFLYNAM0003: Starting Naming Service
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0012: Started server default-server.
> CUSTOM LOG FORMAT INFO [org.wildfly.extension.undertow] WFLYUT0006: Undertow HTTP listener default listening on [0:0:0:0:0:0:0:0]:8080
> CUSTOM LOG FORMAT INFO [org.jboss.as] WFLYSRV0025: WildFly Swarm 2017.8.1 (WildFly Core 2.2.1.Final) started in 257ms - Started 88 of 97 services (18 services are lazy, passive or on-demand)
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 6 months
[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka commented on JBTM-2939:
---------------------------------------
Yes, that's how I understand the case and how I expect this should be handled.
> JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-2939
> URL: https://issues.jboss.org/browse/JBTM-2939
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTS
> Affects Versions: 5.7.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
>
> JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed).
> We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA.
> This came from EAP issue: JBEAP-13023 where you can find more on the reproducing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months
[JBoss JIRA] (JBTM-2939) JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/JBTM-2939?page=com.atlassian.jira.plugin.... ]
Ondra Chaloupka updated JBTM-2939:
----------------------------------
Comment: was deleted
(was: Yes, that's how I understand the case and how I expect this should be handled.)
> JTS for not putting transaction to heuristic state during recovery for XAException.XAER_NOTA
> --------------------------------------------------------------------------------------------
>
> Key: JBTM-2939
> URL: https://issues.jboss.org/browse/JBTM-2939
> Project: JBoss Transaction Manager
> Issue Type: Enhancement
> Components: JTS
> Affects Versions: 5.7.0.Final
> Reporter: Ondra Chaloupka
> Assignee: Ondra Chaloupka
>
> JTS moves transaction to heuristic state when participant during recovery returns {{XAExeption.XAER_NOTA}} error code. This is a bit pointless as this particular error code does not mean that there was some trouble with RM but that RM just already does not know about the transaction branch. For recovery it means that the branch was committed/rolled-back either before recovery started or in some previous recovery run (where probably something crashed).
> We can assumed the transaction was completed and ignore the {{XAER_NOTA}} (in case of recovery). This behaviour is already present in JTA.
> This came from EAP issue: JBEAP-13023 where you can find more on the reproducing.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
6 years, 7 months