Monday, May 14, 2012

A day of staring at the debugger...

Today I sat down to see how well the Metadata Sharing module works with OpenMRS 1.9. We really wan to use OpenMRS 1.9 (to take advantage of the new data model for Visits) and we also want to use MDS (to help us package up new versions of our application content), but they don't fully work together yet.

In the long run we want to use MDS to publish versioned packages containing the metadata and content that makes our application work. I figure we'll have a package for core stuff like Encounter Types, Visit Types, etc, one package for the master list of Locations, and another that contains forms, concepts, and reports. Offhand I think it will be easier to manage changes that way, rather than with a single "everything" package, but time will tell on that front.

Anyway, I was able to get my first example of loading a metadata package when a module starts up (using a placeholder package with a few Encounter Types and Visit Types). You can see the code here. At some point someone in Kenya with domain knowledge is going to have to build the proper first version.

Tomorrow's goals:

  • rename the Distribution module, since Burke didn't like that name) and release it to the OpenMRS module repository.
  • end-to-end test of everything we've built so far:
    • start with an empty standalone installation
    • installing our zip-of-omods (resulting in a running application)
    • installing version 2 of our zip-of-omods (resulting in an updated application)
Yes, it will be as riveting as it sounds. Stay tuned!

Below the fold are a couple of dev issues that took me time to figure out, and I want to document for posterity...

1. When I cloned MDS from github, it failed to build. It builds fine for Rafal, though I don't think it should... :-) Anyway I created an OpenMRS ticket, but the solution was just to @Ignore the test cases, since they're using old zip files in the wrong format. That one didn't take too long to figure out, and hopefully it will be fixed before you need to care.

2. When I first wrote the few lines of code to load a metadata package from my module's resources folder, I got an ugly stacktrace, which google was of no help with. It took me several hours of staring at the debugger to finally get to the bottom of it, so I'll save you the time.
If you want to include a metadata sharing package in your module, in api/src/main/resources, remember that our standard maven module configuration filters the files in src/main/resources!

The solution (properly documented here) is to change your api's pom.xml as follows:
<build>  <resources>    <resource>      <directory>src/main/resources</directory>      <excludes>        <exclude>**/*.zip</exclude>      </excludes>      <filtering>true</filtering>    </resource>    <resource>      <directory>src/main/resources</directory>      <includes>        <include>**/*.zip</include>      </includes>      <filtering>false</filtering>    </resource>  </resources>
 For search engines, the relevant snippet from the stack trace was:
Caused by: incomplete dynamic bit lengths tree
at sun.nio.cs.StreamDecoder.readBytes(
at sun.nio.cs.StreamDecoder.implRead(
at org.openmrs.module.metadatasharing.wrapper.PackageContainer.loadSerializedPackageStream(
at org.openmrs.module.kenyaemr.KenyaEmrActivator.installMetadataPackageIfNecessary(
at org.openmrs.module.kenyaemr.KenyaEmrActivator.setupInitialData(
at org.openmrs.module.kenyaemr.KenyaEmrActivator.started(
... 32 more

No comments:

Post a Comment