[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)]

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

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

The issue consists two parts

First is the WARNING in the log, shown by the REST EASY (`WARN  [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-3) RESTEASY002142: Multiple resource methods`, which I think is not necessary to have. It's about creation one REST endpoind and let it handled programatically based on the accept header content what type of the response is returned.

The second part is about different status being returned. That way the fix of having both methods (or both implementations) returning the `Response.noContent().build()` will fix the thing (plus adjusting javadoc and comments appropriately).

Well , with info from your comment  I can prepare the fix now, if you don't mind, and you can then validate if it's ok.

> 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)