REST WS: which resource will be picked up at runtime?

Ask OpenMRS
, ,
1

Hi all,

When looking at ObsResource in the REST Web Services module version 2.12 I find that

  1. ObsResource1_11 supports versions {"1.11.*", "1.12.*”}

  2. ObsResource1_9 supports versions {"1.9.*", "1.10.*", "1.11.*", "1.12.*”}

(Q.) What happens when I run Core 1.11.x with version 2.12 of the module, is it ObsResource1_11 or ObsResource1_9 that is being picked up?

P.S. I see that on the master branch all supported version ranges are perfectly complementary. Does that mean that tag 2.12 was left in an invalid/ambiguous state?

2

dear @mksd

cant tell you for sure, but the code deciding which resource class gets called should be here if Im not mistaken

you’ll have to try it out/write a test for it/or mentally figure it out by checking initializeResources() I guess. If no one else has an answer right away.

Am working on feature https://issues.openmrs.org/browse/RESTWS-613 and as part of it trying to refactor this class to get clearer code and better tests to de-mystify it and to be able to easily answer such questions :mag: you are more then welcome to join me on this quest/post suggestions :slight_smile:

3

Peeking at the git history, it looks like what you’re seeing was a mistake, and it’s fixed in RESTWS-563 as part of this commit which is included from version 2.14 onwards.

4

I had a similar query. I see different versions 1.8, 1.9, 1.10, 1.11 and so on. Various resources like ConceptResource, EncounterResource, ObsResource, PersonResource, etc. have been implemented in more than one version (under omod-version). I had a query on how to distinguish between these implementations and where to make implementation changes if required in future.

5

is it generally be forbidden to have for ex.

  • ObsResource1_8 support “1.8.*”
  • ObsResource1_9 support “1.8." and "1.9.”

?

if so should there be a test that checks/prevents that?

6

@darius seems to hint that this kind of overlap is in fact undesired and should be avoided by design. But ok we still don’t know which one would be picked up…

Yes! That would be ideal.

7

+1 to someone adding a test for this.

(For any given class T, there should only be one Resource active in each OpenMRS version. Right? Otherwise this method can’t work reliably.)

8

@teleivo am sure such tests are the type that you enjoy doing. :smile:

9

ohh, how I looove those tests :love_letter:

10

true not sure where exactly it would fail if this is the case, so a test is vital.

I guess there should be at least two different tests right?

  1. Test that the implementation of RestServiceImpl.getResourceBySupportedClass() fails if there are more Resource’s that support the wanted class.

  2. A release-test that prevents that we deploy the module if it contains multiple Resource’s that support the same openmrs version

right?

11

@teleivo shouldn’t normal compile time tests be enough to catch any such?

12

My first thought was that as we build an index of all the resources from a classpath scan, we should test for this problem, and fail (with logging) if there are any violations. And we’d make sure that this method is run as part of the tests of each maven submodule for each api version

This should:

  1. break the tests/build at compile time if there are any mistakes in the webservices.rest module itself
  2. break in runtime (near system startup) if you have a collection of other modules which introduce a violation
13

After adding some tests to RestServiceImpl which also cover the private initializeResources() method responsible for picking up the Resources from the classpath and adding them to maps so we can get Resource’s by name/supported class

I can tell you that if you have multiple resources supporting the same class and openmrs version, like

ObsResource1_11 supports versions {"1.11.", "1.12.”}

ObsResource1_9 supports versions {“1.9.", "1.10.”, "1.11.", "1.12.”}

this will only fail if they have the same order value set in the annotation.

If they have different order values you’ll get the one with the lower order value.

1 Like
14

So when running Core 1.11.4 for instance, it is be ObsResource1_11 that is being picked up because "1.11." is order 1 (whereas it is order 3 for ObsResource1_9)?

15

I cannot exactly say it for the specific version of the webservices module you are using.

The behavior I explained was for the current master branch of the webservices module (in which the ObsResource1_11, ObsResource1_9 do not overlap in openmrs versions anymore).

So if the initializeResources() method of the webservices module you have installed behaves the same way as the current master, then yes.