[
https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin....
]
Ondra Chaloupka commented on JBTM-2954:
---------------------------------------
hi [~mmusgrov],
my idea of the fix is here:
https://github.com/ochaloup/narayana/commit/30d4f36ba9d2216ed25fb7bc7fe30...
It consists from points
* lra status is merged to one method where based on the header the response is returned -
that's how the WARNING is ommitted
* status from the {{Transaction}} is changed to be {{204}} and not {{202}} in case of the
LRA is still available
* the behaviour for the {{application/json}} was changed - in case LRA is active
previously http return code {{200}} with json referring to status was returned, now the
{{204}} referring to the status is returned
Could be checke with curl calls
{code}
curl -i -X POST
http://127.0.0.1:8080/lra-coordinator/start
curl -i -X GET -H "Accept: text/xml"
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
HTTP/1.1 406 Not Acceptable
curl -i -X GET -H "Accept: application/json"
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
HTTP/1.1 406 Not Acceptable
curl -i -X PUT -H "Link:
http://localhost"
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
HTTP/1.1 200 OK
Connection: keep-alive
Long-Running-Action-Recovery:
http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8...
Location:
http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8...
curl -i -X PUT
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f...
HTTP/1.1 200 OK
Connection: keep-alive
Long-Running-Action:
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
{code}
now status is shown
{code}
curl -i -X GET -H "Accept: text/*"
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/plain
Content-Length: 12
Date: Mon, 13 Nov 2017 10:33:13 GMT
Compensating
{code}
and
{code}
curl -i -X GET -H "Accept: application/*"
http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 385
Date: Mon, 13 Nov 2017 10:33:03 GMT
{"lraId":"http://127.0.0.1:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f","clientId":"","httpStatus":200,"responseData":"Compensating","status":"Compensating","recovering":true,"compensating":true,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"completing":false,"encodedResponseData":"Compensating","topLevel":true,"active":false,"completed":false}
{code}
What do you think?
LRA coordinator REST endpoint is ambiguous if no Accept header is
defined and for noContent is http status 204
--------------------------------------------------------------------------------------------------------------
Key: JBTM-2954
URL:
https://issues.jboss.org/browse/JBTM-2954
Project: JBoss Transaction Manager
Issue Type: Bug
Components: LRA
Affects Versions: 5.7.1.Final
Reporter: Ondra Chaloupka
Assignee: Michael Musgrove
If you a status check from the lra coordinator then you will receive this warning if the
client does not define {{Accept}} header.
{code}
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple
resource methods match request "GET
/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f". Selecting one. Matching
methods: [public javax.ws.rs.core.Response
io.narayana.lra.coordinator.api.Coordinator.getLRAStatus(java.lang.String) throws
javax.ws.rs.NotFoundException, public io.narayana.lra.coordinator.domain.model.LRAStatus
io.narayana.lra.coordinator.api.Coordinator.getDetailedLRAStatus(java.lang.String) throws
javax.ws.rs.NotFoundException]
{code}
The reason is that the methods {{getLRAStatus}} and {{getDetailedLRAStatus}} are bound to
the same rest path {{@Path("\{LraId\}")}} and differs only in {{@Produces}} tag
- {{(a)Produces(MediaType.TEXT_PLAIN)}} vs {{(a)Produces(MediaType.APPLICATION_JSON)}}.
If client does not specify the {{Accept}} http header then I think is expected to get
text plain. That works this way now but because of the ambiguity it's not guaranteed.
I was thinking to use JAX-RS header manual validation -
{{@HeaderParam("accept")}} but the both methods work a bit differently in case
of active LRA which was not asked to finish. I'm not sure how to merge them.
{{getLRAStatus}} returns code {{204}} while {{getDetailedLRAStatus}} returns code {{200}}
and the {{202}} is then part of the the json body.
{code}
HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: application/json
Content-Length: 359
Date: Mon, 06 Nov 2017 09:14:44 GMT
{"lraId":"http://localhost:8080/lra-coordinator/0_ffff0a00000a_-1f8fb539_5a0025fe_f","clientId":"abc","httpStatus":202,"responseData":null,"status":null,"encodedResponseData":null,"completing":false,"recovering":false,"compensating":false,"compensated":false,"failedToCompensate":false,"failedToComplete":false,"topLevel":true,"completed":false,"active":true}
{code}
Here could be seen another discrepancy that json returns http status {{202}}
(
https://github.com/jbosstm/narayana/blob/5.7.1.Final/rts/lra/lra-coordina...)
(as said above the real http return status is {{200}}). The the code in the coordinator
seems to count to return code {{Response.noContent()}} which is {{204}} but the comments
refers to {{202}}.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)