Deploying fhir module with conditions to ref-application latest

Tags: #<Tag:0x00007f5699eae290> #<Tag:0x00007f5699eae0b0>

Hello, I have an error while trying to upload fhir module omod to ref app latest 37

Is it because openmrs reference application uses openmrs platform version 2.1 and openmrs Condition was introduce in version 2.2? If yes, how can I upgrade ref-app to use openmrs platform 2.2 or higher for my own deployment

Full stack trace https://pastebin.com/jkvV2KVe

Which version of the fhir module?

1.20.0 it’s not yet released

Restart tomcat and share the new log

https://pastebin.com/0WL1vExa

Is this the entire log?

No, the rest is a repetition of the same logs.

There is nothing in there to show that the module has failed to start. What is the name of the log file?

Just restarted the container. New logs

https://pastebin.com/4hjJanBj

Can you share the .omod of the module that you are trying to install?

I have deployed fhir module fhir-1.20.0-snaphot.omod to openmrs reference application 2.10.0 snapshot build version 2.2 and this works successfully.18

when I deploy the same to openmrs reference application 2.9.0 (latest release), It fails with the error noClassDef for org/Openmrs/Condition. The major difference between the two is the openmrs platform version. @dkayiwa what could be the issue here?

@dkayiwa, this issue is a bit of blocker right now. Any suggestions?

Isn’t this weird?

When running against Core 2.2.x (so that’s within Ref App 2.10.x) you will have a classpath conflict between

  • org.openmrs.Condition coming from Core 2.2.x, and
  • org.openmrs.Condition coming from EMR API.

This is because the api submodule is always depended upon.

@mksd For EMR API, It was changed to

org.openmrs.module.emrapi.conditionslist.Condition

@corneliouzbett i have made a commit to the module. Update and test again.

Thank you @dkayiwa

@dkayiwa your commit seems to get rid of a couple of explicit references to org.openmrs.Condition in favour of a generic Object, in api but also (more surprisingly) in api-2.2.

Why did you have to do that if there is no such collisions? Just curious :wink:

@mksd the interface being implemented by api-2.2 resides in the api project which needs to run on platform versions before 2.2 when org.openmrs.Condition was introduced. Some sort of quick surgical fix. :smile: