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 More → Link; if you don’t see this option, let me know) and send us a pull request. Your help is very much appreciated!
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
The wrapper option is better, but needs more work. And the JPA even better !
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.
@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?
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).
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.
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?
@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
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.