[jbossts-issues] [JBoss JIRA] (JBTM-2954) LRA coordinator REST endpoint is ambiguous if no Accept header is defined and for noContent is http status 204

Ondra Chaloupka (JIRA) issues at jboss.org
Mon Nov 13 05:56:00 EST 2017


    [ https://issues.jboss.org/browse/JBTM-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13489260#comment-13489260 ] 

Ondra Chaloupka commented on JBTM-2954:
---------------------------------------

hi [~mmusgrov],

my idea of the fix is here:
https://github.com/ochaloup/narayana/commit/30d4f36ba9d2216ed25fb7bc7fe306ba51a557f8

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%3A8080%2Flra-coordinator%2F0_ffff0a000007_-4bbc6a89_5a097341_f/0_ffff0a000007_-4bbc6a89_5a097341_18
Location: http://localhost:8080/lra-recovery-coordinator/http%3A%2F%2Flocalhost%3A8080%2Flra-coordinator%2F0_ffff0a000007_-4bbc6a89_5a097341_f/0_ffff0a000007_-4bbc6a89_5a097341_18

curl -i -X PUT http://localhost:8080/lra-coordinator/0_ffff0a000007_-4bbc6a89_5a097341_f/close
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 - {{@Produces(MediaType.TEXT_PLAIN)}} vs {{@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-coordinator/src/main/java/io/narayana/lra/coordinator/domain/model/Transaction.java#L557) (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)


More information about the jbossts-issues mailing list