Thanks so much @mseaton, this worked! I’m am now able to load custom messages defined in a test messages.properties resource. 
Yes!
There is one minor improvement to ObjectUtil#loadPropertiesFromClasspath(String) here.
Change
ret.load(is);
to
ret.load(new InputStreamReader(is, "UTF-8"));
This enables proper loading of special characters from the messages.properties files. At least that’s what I had to do in Address Hierarchy.
Credits: ‘Not getting spanish characters (ú, í )but getting like (ó , Ã) on UI’.
@mogoodrich and @mseaton, I have created ADDR-108: ‘Enable i18n support for address hierarchy entries’.
I can claim this issue if you let me!
You should be okay now to pick it up, I marked it ready for work.
Thanks!
Mark
Hey @mseaton,
So I have rebased master on this configuration branch and added a context sensitive test for the activator to play around with things a little. It’s pretty cool, it does what it needs to do IMHO. You had actually recorded that a configuration had already been processed by saving its md5 checksum into configuration/addresshierarchy/latest_loaded_entries to prevent further reloading. Should I PR this into master? I’m verifying that an untouched config is not reloaded a second time, and of course that the provided configuration is indeed loaded the first time it is provided.
I see what you mean, there is no way currently to verify that the address hierarchy has been modified between two restarts of the activator (such as through the admin UI). But surely this is a refinement that could be brought in at a later stage if it was ever needed? For our sake it is really good enough like this.
@mksd, great - glad it is working for you. For me, just having you try to use this and validate it for your use case gives me enough confidence to merge it in, since it is pretty self-contained from what I recall. If it doesn’t work, that only affects new users of this feature, not existing users, so assuming there are not design disagreements, feel free to push this ahead. Thanks!
Mike
@mseaton @mksd How do I ensure that my address hierarchy is not reloaded at each restart. Your comments seem to indicate that is possible but I do not see how.
You can set the addresshierarchy.initializeAddressHierarchyCacheOnStartup global property to false to prevent caching at startup.
But it depends what you mean by “loading”?
Hi @mseaton,
So I made some changes, added unit tests, was ready to go… and of course I got errors at runtime. Hopefully only this one blocker:
java.lang.NoClassDefFoundError: org/openmrs/layout/web/address/AddressTemplate
This happens I believe because in Core 2.x this class was moved to org/openmrs/layout/address, hence the definition of the class is indeed not being found at runtime against Core 2.x.
I would like your opinion on this: is there a simple workaround that does not involve introducing compatibility classes?
@mksd The address cache is setup at runtime, however my address entries are always loaded from the csv file at startup which adds about a minute each time. The loading from the csv into the database is what I am referring to
That is really strange, did you see this thread: ‘Preloading address template and address hierarchy’?
The behavior that you describe is not implemented yet as part of Address Hierarchy, so if there is an automatic loading of the entries CSV file, it must be performed by another module.
@mksd, is the runtime issue you were hitting with AddressTemplate still an issue? I thought I saw some classes in your latest pull request for @dkayiwa that dealt with this. Happy to talk through it if helpful - find me on IRC.
Mike
Yes, still an issue.
So I did go for a compatibility class (AddressTemplateCompatibility), but now we are hitting a Spring bean problem at runtime.
@dkayiwa is still looking into it.
P.S. I just created ADDR-109 btw.
@mksd, from quickly re-looking at the code, the main purpose is to be able to install the AddressTemplate configuration that the system requires. This is stored as a global property (not sure if it still is in 2.0, but assuming it is), as a serialized string. So, it’s not technically necessary to use the AddressTemplate class from core at all, as long as you can construct the serialized xml that core can read back in.
So, if you are referring to a compatibility class as one that you introduce to be able to hold the address template data, and that will serialize down to the appropriate format in either pre-2.0 and post-2.0, then this is probably the best course of action.
Mike
Yes sure. At first I thought it would be better to just stick to your code that leverages Xstream since everything was in place. Of course now after the fact, I’m left thinking that generating the XML string was a better deal. If there is not an obvious solution to the Spring error happening at runtime I will have to go down that route.
I used reflection as suggested @dkayiwa using just this.
In that very instance about AddressTemplate, reflection has provided to be a far better solution than dealing with compatibility classes.
Unless we hit yet another unexpected issue at runtime, this is good to go.
