REST module Concept Mapping error

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.

1 Like

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