- 25 Jul 2008 -

I was recently tasked with finding out the number of methods in each class in each package inside of OpenMRS. My first thought was to write a java class to do some reflection. My second thought was to find a java class that someone else had written and use that. My third thought was to find a way for Eclipse to do it.

I really should have jumped to that last one first.  Googling for my second thought gave me nothing useful.  However, simply adding “eclipse” to my search term brought up the Metrics plugin as the first result!  The Metrics plugin counts all different types of things.  Lucky for me, “number of methods” just happens to be one of them.

To get the counts working for you, follow these easy steps:

  1. Add http://metrics.sourceforge.net/update to eclipse as a plugin update site
  2. Turn metrics on for your project:
    1. Right click on the root of your project in Package Explorer view
    2. Choose Properties–>Metrics–>Enable Metrics
  3. Do an Eclipse clean rebuild
  4. Click on the root of your project in the Package Explorer
  5. Open the “Metrics” view

These are the relevant statistics from the OpenMRS project:

The second api/web are from the test package.  We have a lot of work to do to catch our total number of unit test methods up with our number of api methods.

I’ve also uploaded the entire OpenMRS metrics output.

This is in the openmrs category tagged as , ,

Add a comment »

I attended a session today at the MySQLConf2008 by Mark Matthews on adding extensions to the mysql jdbc connector. There are some exciting implications as an alternative to the BIRT ODA Plugin project. The idea of that project is to create a series of REST calls to only require the end user of the BIRT reporting application to have a high level knowledge of OpenMRS objects (instead of low level knowledge of the OpenMRS data model).

Sometime last year Burke laid out his dream BIRT (or other reporting frameworks) connection. It entailed writing a custom jdbc connector that didn’t act on the database, but instead acted on our API. The “available tables” as the user would see it in BIRT would actually be a subset of our higher level Java objects.

In the session Mark discussed the new intercept-ability of the MySQL Connector/J (new in version 5.1ga of the connector). The relevant/interesting addition to the connector is the “statement interceptor”. We could use this to intercept the select calls from BIRT that look like “SELECT AGE, GENDER, WEIGHT, HEIGHT, LATEST CD4 FROM PATIENT WHERE DATE > 1/1/2008″. These calls could be turned into some LogicService calls on AGE, WEIGHT, LATEST CD4, etc to get the ResultSet instead of passing that (unusable) query to mysql. The LogicService’s resultSet could then be returned to BIRT for display as a data set. There isn’t any documentation on MySQL Forge on how this would work yet. Mark’s slides should show up as an option on the mysqlconf’s wiki soon though.

Side note: The jdbc driver’s version number does not match with the mysql version numbers. Version 5.1 of the driver can be used with the current 5.0 of MySQL.

This is in the openmrs category tagged as , ,

Add a comment »

I’m going to post this here as a reminder to other OpenMRS developers (and myself) and to hopefully save a few hours/days of debugging. The key to getting transactions to work correctly in the webapp is to, well, tell Spring that we’re in a transaction. You can do this by simply putting an @Transactional annotation in the *Service java interface.

Without that key piece of text, the service and its methods will still work. However, they’ll work in a readonly kind of way. All data written to the database will be rolled back when the body of work has completed. This little error manifested itself recently after our reporting code-a-thon. During the event we had to create a new API service, which is only done maybe a few times a year. The service didn’t get the @Transactional tag and so therefore all database editing failed that went through the ReportService. The unit tests set up for the object passed, but that is because a unit test happens all within a single transaction — the rollback is always done after the completion of the test anyway.

I added a note to http://openmrs.org/wiki/OpenMRS_API about the requirement, but I’m sure there will be an OpenMRS developer in the future struggling with their object not saving or updating in the database and be completely baffled by it.

This is in the openmrs category tagged as , , ,

Add a comment »

I recently had a very frustrating error that I want to document here for future Googling’s sake. After a non-ideal shutdown of Tomcat and/or the jvm I was unable to start the OpenMRS webapp. Tomcat was giving this error in its log file:

Failed to read schema document 'http://www.springframework.org/schema/beans/spring-beans.xsd'

This is somewhat expected with the move from Spring 2.0 to 2.5. As of Spring Framework 2.5 the new url to use in the application context is

http://www.springframework.org/schema/beans/spring-beans-2.5.xsd

but even after making this change in the code and redeploying the webapp, Tomcat refused to start giving the same url (with just spring-beans.xsd).

Solution:

A Spring definition file (namely applicationContext-service.xml) was being cached in Tomcat’s work directory and not being replaced on webapp deploy for some reason. I uninstalled the webapp and then deleted all files under <tomcathome>/work/localhost. Upon installing openmrs and starting Tomcat again everything started up as expected.

This is in the openmrs category tagged as , ,

Add a comment »

I recently had the pleasure of setting up an ant build of OpenMRS on our new servers. After installing ant and the OpenMRS source code I kept getting a never-before-seen error when building:

No supported regular expression matcher found

I made sure I had jdk 1.6 installed. I tried upgrading to Ant 1.7 (from 1.6.5).

I ran an “ant -diagnostics”. It wasn’t showing the optional ant jars so I dropped all of the jars into the ant home lib directory. Now the jars were showing up but I was still getting the same error as before.

The solution ended up being that Ant lied to me. It was actually looking for the jars in /usr/share/java/ant (not in its reported /usr/share/ant). The puzzling thing is that Ant tells me it finds the jars when running “ant -diagnostics”.

I ended up installing the optional ant jars via yum. (or apt-get if you’re on a debian flavor) Yum didn’t have the explicit ant-optional package, so I just installed all ant-*.jar files. Voila! Successful building via ant is now possible.

This is in the openmrs category tagged as , ,

1 comment »

« Previous Entries