Hi @darius,
Would you mind reading through the recent posts on this thread? In particular you may have ideas as to the reason why some inner JsonNode instances are nullified when sent over the wire.
This would help nail RA-951 once and for all.
@mksd sure, I’ll look at it this week. I know about this general problem (Jackson nodes not fitting nicely with other technologies that let you look up properties). Mark and I ran into it before Can you point me to exactly which file is reading the config in this case?
Speaking very generally…this is a big mess.
Our intention in having this simple JSON config with no fancy Java types was so that the same config format could drive both server-side Java/Groovy apps, and client-side JS apps. I do still think this approach is valuable, since the world continues to move towards client-side JS (even though in practice the Bahmni team’s app config format isn’t actually compatible).
This cleanup method is an ugly example of a workaround.
My advice would be to create a utility method that converts an ObjectNode to a Map<String, Object> that Groovy can handle, and that whenever you have config that’s coming from Jackson (i.e. you have an ObjectNode) and you want to access from Groovy, use this utility method.
I would do the implementation by having Jackson write to a String, and using Groovy’s JsonSlurper to parse it back in. (You might want to verify this isn’t a meaningful performance hit for the smallish config files we have.) If performance is a problem, you could have a wrapper that implements Map but delegates to the ObjectNode for its get method.
(I’m assuming there’s some point in the code, e.g. in registrationapp, where we know that we’ve got an ObjectNode providing our config.)
Hi @darius, thanks for this.
A few weeks back, when I was looking at it, I went down the JsonSlurper route (as I was obviously Googling around for ways to unmarshall JSON strings in Groovy) and the library was not recognised. I’m just recalling from the top of my head where I got blocked but I don’t have the exact error that was thrown at hand right now.
As I said, I am not really familiar with this GSP tech at all, what would I have to do to ensure that yet another utility such as JsonSlurper can be used within OpenMRS GSP pages?
You can add utility methods to UiUtils in the uiframework module, and they’re accessible as ui.xyz() in a GSP page.
Any chance we have a failing unit test that illustrates this specific bug?