Maybe because of this?
supportedOpenmrsVersions = {"1.9.*", "1.10.*"}
Maybe because of this?
supportedOpenmrsVersions = {"1.9.*", "1.10.*"}
@darius, thank you for your help.
Apparently when I execute GET /openmrs/ws/rest/v1/concept/CIEL:1065
ConceptResource1_9.getByUniqueId
gets called. However when I do a POST
to /openmrs/ws/rest/v1/encounter
with the payload that I shared, none of these methods ConceptResource1_8.getByUniqueId
and ConceptResource1_9.getByUniqueId
get Called.
Thanks for helping explore this. I figured out the problem. There are two mistakes, in ObsResource1_9
and ObsResource1_11
.
ObsResource1_9
incorrectly says
supportedOpenmrsVersions = {"1.9.*", "1.10.*", "1.11.*", "1.12.*", "2.0.*"}
But it should only be 1.9.*, 1.10.*
ObsResource1_11
incorrectly extends ObsResource1_8
, but it should extend ObsResource1_9
.
@werick can you create a ticket in the RESTWS project on http://issues.openmrs.org to describe this bug, and send a PR with these small changes? (Or anyone can, really.)
Ok. Am doing that right away and will share create the ticket and PR as well.
Here is the PR for ticket for you to review on
https://github.com/openmrs/openmrs-module-webservices.rest/pull/192
Seems to me that a similar issue like this can arise again for another resource or even that it is actually happening for another resource since this seems like an easy mistake for a dev to make when adding a resource that supports a later version of OpenMRS Platform
Not sure how to get around it to avoid the same going forward, may be a unit test
Yes, it seems worthwhile to write a unit test that loads all the resources, and ensures that there are never two resources that handle the same class, with overlapping OpenMRS versions.
Just for the sake of completeness, ObsResource1_11 was added after ObsResource1_8 which explains why it was the base class. Then later on, while RESTWS-499 was being done, ObsResource1_9 was introduced. It is during this ticket that ObsResource1_11’s base class should then have been changed to the new ObsResource1_9.
It’s a perversion of inheritance IMHO (also very confusing and not scalable)
This is why a unit test is needed to catch the issue when it arises again