Dashboard Widgets broken on http://qa-refapp.openmrs.org

@raff Please do help here, I have just noticed that the dashboard widgets do not seem to be working on https://qa-refapp.openmrs.org but no idea where to dig in

  1. I have seen an error that this file https://qa-refapp.openmrs.org/openmrs/module/uicommons/messages/messages.json?localeKey=en_US cannot be loaded

  2. This file too is not loaded https://qa-refapp.openmrs.org/openmrs/ms/uiframework/resource/uicommons/scripts/datetimepicker/locales/bootstrap-datetimepicker.en_GB.js?cache=1510753879066

  3. The Family widget also shows coreapps.none which points to #1 not working

  4. The latest observations and weight widgets are also empty yet they should have text.

  5. Also seen this WARNING: Tried to load angular more than once in the console with reference to the angular.js library file

I think I may know what is going on here, let me take a look now.

@ssmusoke @raff

Okay, so it wasn’t what I though it was… I though it might have been due to a change I had to make to key used to specify the locale when fetching message codes RESTfully, but that all sees to be working okay.

What is happening is that this:

https://qa-refapp.openmrs.org/openmrs/module/uicommons/messages/messages.json?localeKey=en_US

isn’t falling back to:

https://qa-refapp.openmrs.org/openmrs/module/uicommons/messages/messages.json?localeKey=en

Strangely, if I do change the locale to “en”, the messages.json seems to load correctly, but the codes still aren’t being resolved.

I will see if I can investigate further later today.

Take care, Mark

Further testing shows that although “localeKey=en” is loading, the message keys returned are only those from OpenMRS Core (or at least the modules I spot-checked were missing).

I’m wondering if perhaps this initialization step that preloads all them message codes into a map didn’t pick up the module codes for some reason?

I was also wondering if this was perhaps a transitory thing… I didn’t know how to restart the refapp server, so retriggered the build, and it did appear to restart the server, but I’m still seeing the same problem.

Unfortunately, I’m not sure how to debug further… there certainly could be some issues in the code I wrote to load message maps (see above) but (so far, at least) things are working for me locally and on our bamboo pipeline… I think I’d need to able log into the qa-refapp server and perhaps run a debugger against it to test further.

I’ll continue to keep an eye to see if I can reproduce locally.

@ssmusoke… any idea if this problem just started to occur? Would be great if we could track it down to a certain commit or range of commits.

Take care, Mark

@mogoodrich I am looking at different modules as a means of tracing where the cause is…

Cool, keep me posted and I can look into things… it could certainly be a symptom of my code but hard for me to debug since I can’t reproduce locally.

Take care, Mark

@mogoodrich a thought can you share the list of modules and their versions that you are running. That way I just look at the ones that are different in setups with the error.

Here’s the link to our latest distro pom, which lists all the modules:

It would interesting to know if anyone running the Ref App locally can reproduce the problem. Also, is it on any other of our staging servers?

Take care, Mark

Same thing happens on https://uat-refapp.openmrs.org/openmrs/coreapps/clinicianfacing/patient.page?patientId=ac5b7f58-a1d6-4f0d-b7df-5ec24ed8bbad

I’ll have a look at it.

Update: I was able to reproduce it running RA via docker. Steps to reproduce:

  1. Build openmrs-distro-referenceapplication
  2. Go to package/target/distro
  3. Run docker-compose up

I’m trying to attach a debugger to see what’s going on.

Update: Found a bug in uicommons. I’ll fix and commit.

@raff excellent

@tendomart Do keep an eye as uicommons version will have to be updated

1 Like

Thanks @raff… though I don’t see the commit yet? (I’m curious because I suspect it was my fault :slight_smile: and a problem with the MessagesController. Just hard for me to debug since I couldn’t reproduce).

Take care, Mark

Sorry, it was misleading…

So the bug I found was with https://github.com/openmrs/openmrs-module-uicommons/blob/master/omod/src/main/java/org/openmrs/module/uicommons/message/MessagesController.java#L105 Basically, if adminService.getPresentationLocales() has ‘en’ and ‘en_GB’ listed then en_GB overwrites the en map in that line.

However, fixing that didn’t help.

I tracked it further down to be an issue in openmrs-core 2.0.x+. Basically messageSourceService.getPresentations() is not returning any messages from modules, however messageSourceService.getMessage(…) does look up codes in modules’ messages (I’m guessing it’s not using getPresentations()).

Basically findPropertiesFiles does not work for some reason. The implementation has been changed in openmrs-core 2.0.x entirely.

I will continue with that on Monday…

Ah, got it, thanks @raff

And, yeah, having it be a issue with Core does make sense, because it where the reference app differs most from the PIH EMR… we are still running 1.10.x Core in the PIH EMR.

Take care, Mark

@ssmusoke alright thanks alot for the notification…

@dkayiwa I identified the issue to be caused by TRUNK-4097. If you run RA 2.7.0-SNAPSHOT and go to the patient dashboard you will see “coreapps.none” message under Family even though the translation is defined in coreapps (it’s loaded via a rest call to the uicommons/messages endpoint). The issue is with modifications you made to findPropertiesFiles, which returns only properties found in openmrs-core, but not in modules. I was looking for a way to fix it, but with no avail so far. Maybe, you could have a look as well…

findPropertiesFiles is using PathMatchingResourcePatternResolver and docs say:

WARNING: Note that “classpath*:” when combined with Ant-style patterns will only work reliably with at least one root directory before the pattern starts, unless the actual target files reside in the file system. This means that a pattern like “classpath*:*.xml” will not retrieve files from the root of jar files but rather only from the root of expanded directories. This originates from a limitation in the JDK’s ClassLoader.getResources() method which only returns file system locations for a passed-in empty String (indicating potential roots to search). This ResourcePatternResolver implementation is trying to mitigate the jar root lookup limitation through URLClassLoader introspection and “java.class.path” manifest evaluation; however, without portability guarantees.

Basically it’s what we are observing. We need to rewrite it to use a different approach for finding message files as they are always stored at the root.

@raff could you be knowing why it is working well on http://demo.openmrs.org/ which is also using platform 2.x?

@dkayiwa, demo server has coreapps 1.13.0, which does not use translations: https://github.com/openmrs/openmrs-module-coreapps/blob/1.13.0/omod/src/main/webapp/resources/scripts/fragments/dashboardwidgets/relationships/relationships.html#L18

Can you test this change to see if it fixes the reported problem? https://issues.openmrs.org/browse/TRUNK-5239

@dkayiwa The issue still happens in coreapps as Family still has coreapps.none with no relationships