SessionFactory issue after Hibernate 4 upgrade

As it stands now, you CANNOT use most of modules when running OpenMRS Platform 1.12.

It is due to, which I created for Html Form Entry, but it is the case for any module that uses SessionFactory (practically all modules).

I’d like your comments on the issue. Please speak up, if you think there is a better solution than what I suggested there.


We decided to go with the DbSession approach.

We now need your help with fixing other modules to use it so that they can run on OpenMRS Platform 1.12. It’s a very simple fix, an example of which you can find at

The way to help is to create an issue for a module of your choice, create the “is depended on by” link to TRUNK-4713 (in the menu, click MoreLink; if you don’t see this option, let me know) and send us a pull request. Your help is very much appreciated!

The list of modules, which need to be checked:

  1. Atlas Module
  2. Form Entry App Module
  3. Reporting
  4. Metadata Sharing
  5. ID Generation
  6. EMR API Module
  7. Allergy UI Module
  8. Registration App Module
  9. HTML Form Entry UI Framework Integration Module
  10. App Framework Module
  11. Reporting REST
  12. Reference Metadata Module
  13. Metadata Mapping
  14. Metadata Deploy
  15. Reference Application Module
  16. OpenMRS UI Framework
  17. App UI Module
  18. HTML Widgets
  19. Serialization Xstream [DONE]
  20. Registration Core Module
  21. HTML Form Entry Extensions for OpenMRS 1.9 Module
  22. Event Module
  23. Core Apps Module
  24. Provider Management Module
  25. Chart Search Module
  26. Calculation
  27. Allergy API Module
  28. Appointment Scheduling UI Module
  29. HTML Form Entry [DONE]
  30. UI Commons Module
  31. Rest Web Services
  32. Appointment Scheduling Module
  33. Data Exchange Module
  34. UI Library Module
  35. Reference Demo Data Module
1 Like

Of the three options you suggest, I like the first one (compile with Hibernate 4). As the API hasn’t changed (just the package) it’s just a matter of refreshing the imports, no refactoring needed. But it’s the option you don’t like :smile:

The wrapper option is better, but needs more work. And the JPA even better !

1 Like

To clarify compiling for Hibernate 4 (in practice OpenMRS Platform 1.12) means we have to ask module developers to release a version of an omod that can only run on OpenMRS Platform 1.12 and another version of an omod that can run on OpenMRS Platform versions before 1.12. In order to achieve that in some cases it may be needed to maintain a separate branch in module’s repository.

So the decision was to go with the DbSession approach.

Burke’s edit: @raff, I moved the list of modules to be checked/fixed as an update to your original post. You can use <strike></strike> to cross off modules as they’re addressed.

@raff Thanks for the information on this. Just so I’m clear, if we update our modules to use this new DbSessionFactory class will we get support for both Hibernate 3 and Hibernate 4 versions of OpenMRS?

Yes, your module will run on Hibernate 3 and Hibernate 4 versions of OpenMRS. Obviously, if you want to use features of Hibernate 4 you must run OpenMRS Platform 1.12.

Making this change will mean that to use the latest version of any of these modules, implementations will have to upgrade to the very latest versions of 1.9.x, 1.10.x, or 1.11.x, and these new versions are not released yet.

My recommendation is that we do not update these modules until we have actually released the core versions. (Especially for any that commonly have new versions released in between OpenMRS releases).


I just made a similar comment on the relevant Html Form Entry ticket…


Very good point, @darius. I don’t suppose there’s an easy way to mitigate against this? Any chance a small temporary library could do the messy work of only introducing DbSessionFactory if it isn’t already provided by core? For example, try a class.forName() and introduce its DbSessionFactory & DbSession if that fails. Then modules could be refactored, add one new dependency (to a “DbSession-only-if-its-needed” library) and work in older/current implementations.

I was hoping we could simply release maintenance versions in the coming week so as we do not loose the momentum.

It’s almost a year since the last release of 1.9.x branch and about half a year for 1.10.x.

Given the widespread effect Hibernate4 on modules, has there been any thought of reverting to Hibernate3 on master and putting Hibernate4 on a branch until more work is done? Or is the consensus that staying on master is easier and will help push this forward?

The reason I ask is as of April 2015 it was possible to run the reference application on 1.12 with all but 2 modules. Now apparently most of the modules are broken. Even after they are all fixed, they will also have to be released before it is convenient to download + install them to run with 1.12.

I don’t know how much of a consideration this really is, i.e. how many module authors develop against 1.12 master instead of 1.11, but for any that do, it seems like there will be a lot of other peoples’ module dependencies that are going to have to be fixed first.

@kristopherschmidt, module authors usually develop against released versions of OpenMRS Platform or SNAPSHOTs from branches of released versions (e.g. 1.11.x, 1.10.x, 1.9.x).

Introducing Hibernate 4 is basically done on the OpenMRS Platform side (tests passing, application working), thus I have merged the branch. We now need to adjust modules. It can be easier accomplished having incompatibilities in master rather than in some branch. If you do not follow the development of OpenMRS Platform you can still easily discover that your module does not run against master now and you should probably take some actions to fix it. The sooner more devs realize about that the better for the platform.

I’d like to clarify the JIRA process for tracking these module changes. I see there is a master case TRUNK-4364 with sub-tasks to update the modules, which is great (e.g. TRUNK-4705 HTML Form Entry module must be fixed to work with Hibernate 4). However, I see that TRUNK-4705 in turn mentions HTML-594 (Module must be fixed to work with OpenMRS 1.12).

Right now is that there is no direct link between TRUNK-4364 and HTML-594. Confusing things further, TRUNK-4705 has been Closed but HTML-594 is still open (PR unmerged). So from the top-level it looks like htmlformentry work is completely done, when in fact there is still an open PR.

Might I suggest that instead of creating sub-tasks in TRUNK-4364, we go straight to creating a task in the appropriate module, and create a depends-on link? That way going forward we only have 1 level of tasks to do, and they are tracked all the way through?

@kristopherschmidt, I needed to close TRUNK-4705 prematurely, because it had commits in core, which were back ported to OpenMRS Platform versions I am about to release. I wouldn’t close it otherwise until merged.

Having another look I do agree that we don’t need subtasks. Depends-on links suffice. There’s no need to duplicate issues with sub-tasks. I’ve created TRUNK-4713 to gather depends-on links (and updated the first post with instructions).


Rafal, if you are releasing maintenance versions of 1.9, 1.10, 1.11 to add the new DbSession code, please take a look at my suggestion here:

Basically the javassist library needs to be updated to fix issues when running JUnit tests against Java 8. If that update can be backported and rolled into the new releases, it will prevent having to fix every module that uses powermock. (every module needs to update the core version anyway, so the javassist fix will come along for free) Make sense?

As part of the work we did to support java 8, i recall like we already updated javaassist

@kristopherschmidt, javaassist is used in key parts like Spring and Hibernate proxies. I am reluctant to update the version without doing extensive testing before releasing, which I didn’t plan for.

A module author can always overwrite the version of javassist in module’s pom to make it work with Java 8 or declare a dependency on the latest OpenMRS platform version.

@raff did you see my comment? We already upgraded javassist as part of the java 8 work

@wyclif javassist was upgraded on master for 1.12, but the issue I encountered was with with modules depending on earlier versions of core. I think Rafal meant that he doesn’t want to backport the upgrade to javassist, as that would require more testing on say 1.9.10, 1.10.2, etc

1 Like

So… if we start to work on this and find modules using core versions earlier than 1.9, we take the liberty of updating them to 1.9.10 (after it is released)? For instance I went to update Atlas and found that it is built against 1.7.4. Just want to make sure this is the right approach and find out if there are any caveats around jumping modules up by several core version numbers.