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

ssmusoke · November 15, 2017, 4:13pm

@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

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
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
The Family widget also shows coreapps.none which points to #1 not working
The latest observations and weight widgets are also empty yet they should have text.
Also seen this WARNING: Tried to load angular more than once in the console with reference to the angular.js library file

mogoodrich · November 15, 2017, 6:10pm

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

@ssmusoke @raff

mogoodrich · November 15, 2017, 6:29pm

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

mogoodrich · November 15, 2017, 7:22pm

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?

github.com

openmrs/openmrs-module-uicommons/blob/master/omod/src/main/java/org/openmrs/module/uicommons/message/MessagesController.java#L55




private Object lock = new Object();


@RequestMapping(value = "/module/uicommons/messages/messages.json", method = RequestMethod.GET)
@ResponseBody
public ResponseEntity<Map<String,String>> getMessages(@RequestParam("localeKey") Locale localeKey, WebRequest webRequest) {


    // TODO zip to compress?


    // I tried to handle this in a @PostConstruct method but ran into issues--it seems like some of the resources required weren't actually available yet?
    synchronized (lock) {
        if (!initialized) {
            initializeKeySet();
            initializeLocales();


            // we were running into some odd, tranistory cases where the messages weren't being initialized;
            // so we only flag as initialized if something has been populated, see RA-1463
            if (codes != null && codes.size() > 0 && messages != null && messages.size() > 0) {
                initialized = true;
            }
        }

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

ssmusoke · November 16, 2017, 3:55pm

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

mogoodrich · November 16, 2017, 6:39pm

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

ssmusoke · November 16, 2017, 6:50pm

@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.

mogoodrich · November 16, 2017, 6:58pm

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

github.com

PIH/openmrs-module-mirebalais/blob/master/pom.xml#L54




<modules>
    <module>test-resources</module>
    <module>api</module>
    <module>omod</module>
    <module>distro</module>
    <module>ci</module>
</modules>


<properties>
    <openMRSVersion>2.1.3</openMRSVersion>
    <openMRSwebVersion>2.1.3</openMRSwebVersion>
    <pihcoreVersion>1.0-SNAPSHOT</pihcoreVersion>
    <mirebalaismetadataVersion>1.0-SNAPSHOT</mirebalaismetadataVersion>
    <mirebalaisreportsVersion>1.1-SNAPSHOT</mirebalaisreportsVersion>
    <edtriageappVersion>1.1.0-SNAPSHOT</edtriageappVersion>
    <emrapiVersion>1.25.0-SNAPSHOT</emrapiVersion>
    <paperrecordVersion>1.3.0</paperrecordVersion>
    <emrVersion>2.1.0</emrVersion>
    <uiframeworkVersion>3.13.0</uiframeworkVersion>
    <appframeworkVersion>2.11.0</appframeworkVersion>

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

raff · November 17, 2017, 10:11am

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:

Build openmrs-distro-referenceapplication
Go to package/target/distro
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.

ssmusoke · November 17, 2017, 2:42pm

@raff excellent

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

mogoodrich · November 17, 2017, 2:57pm

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

Take care, Mark

raff · November 17, 2017, 7:45pm

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…

mogoodrich · November 17, 2017, 9:39pm

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

tendomart · November 20, 2017, 5:58am

@ssmusoke alright thanks alot for the notification…

raff · November 23, 2017, 3:17pm

@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…

raff · November 24, 2017, 11:20am

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.

dkayiwa · November 24, 2017, 11:29am

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

raff · November 24, 2017, 11:52am

@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

dkayiwa · November 26, 2017, 8:23pm

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

ssmusoke · November 27, 2017, 5:18am

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