@mogoodrich Is is possible to put a webModuleApplicationContext.xml file in version-specific sub-module? We could solve things that way.
Basically what we need is a way to only load that bean definition for certain versions of OpenMRS.
Seems feasible, I’ve never been deeply involved in the submodule stuff for supporting earlier versions of OpenMRS, but we seem to have had luck with it… any thoughts @dkayiwa?
It also might be worth checking posting on Talk and asking specifically if any of the major distros are still running pre-1.12.x versions. The PIH EMR is 2.x, but our Rwanda and Malawi implementations are not yet on the “PIH EMR” distro and are running 1.9.x, though we are hoping to upgrade them sooner rather than later.
Take care, Mark
1 Like
We already have multiple ways of dealing with this sort of thing and we have been doing it for modules whenever there are such platform changes.
@sharif are these resources of help? https://wiki.openmrs.org/display/docs/Supporting+Platform+2.0+and+below
https://wiki.openmrs.org/pages/viewpage.action?pageId=60067371
@ibacher it would be easier to conditionally load such a bean in Java instead of xml just like i did here https://github.com/openmrs/openmrs-module-webservices.rest/commit/a25cad5c749e9add5c0005b2d6f342dd06c9f7a2
1 Like
@ibacher that commit could even be improved by replacing the thrown expensive exceptions with explicitly checking the running OpenMRS platform version, and then load the appropriate bean as done here: https://github.com/openmrs/openmrs-module-htmlformentry/commit/e32d6e5a390f22a970f3031e3a7c73e662395fbe
1 Like
@ibacher thanks alot for great work and thanks for updating the Trunk-5722. is it possible to review and guide me on this ticket, it seems you changed to blocker un resolved
Thanks @sharif @ibacher @dkayiwa! Sorry to be a nuisance… to be clear, if it ever becomes a real pain to maintain backwards compatibility back that far in modules, we should definitely reconsider, but if there is a straightforward path that allows us not to have to branch modules, we should take it.
Take care, Mark
1 Like
@ibacher , regrading java Upgrade , is there a way we can move towards java 11 and yet still be compatible with 8 ??
that seems to me like like we will use conditional beans/Resources to load the different java libraries in the Core.
Or rather Modules will use conditional resources to be compatible with different Openmrs core API versions
some more insight into that
@mozzy AFAICT the only thing in the platform that is definitively working in Java 8 and broken in Java 9 and newer is the ShouldTaglet. This is broken because it depends on internal classes from the sun package that have been deprecated. Currently, we’re in the process of removing the ShouldTaglet altogether. Once that’s done, we need to upgrade some libraries, but the big ones (Spring and Hibernate) have already been done, and the new versions of those are still compatible with Java 8.
As I see it, moving towards Java 11 is primarily about being able to run on Java 11 and newer rather than compiling a version specifically for Java 11 or taking advantage of any of the new features.
When we get to the point where we want to take advantage of new language features, we can take advantage of the Java module system introduced in Java 9 to maintain enhanced versions of classes that only load on specified Java versions or newer, leaving as much of the codebase as possible able to be run on Java 8.
If we get to the point where we’re building functionality that can only be supported in newer versions of Java, then we might need to introduce OpenMRS 3.x, but until then, we should be supporting Java 8 as long as possible.
@ibacher , i think that makes sence then .
Ideally if we arent focussing on taking advantage of new version specific features, but rather simply being abe to run on it , then that makes sense . no wonder i was insisting a bump to core version 3.0 . 
, but now that makes sense.
Hi folks,
When I try to setup a new instance of Ref App 2.11.0 using the openmrs-sdk, i.e.,
mvn -e openmrs-sdk:setup -Ddistro=org.openmrs.distro:referenceapplication-package:2.11.0-SNAPSHOT
I am experiencing some issues which seem to be related to the topic of this thread (i.e., Spring upgrade). I have pasted some of the initial error messages here (there are many others because of dependency injection failures of sessionFactory). But AFAICT, the openmrs-servlet.xml in that distro already has this commit hence I am a little confused what causes those initial errors, e.g., for ParameterMethodNameResolver or DefaultAnnotationHandlerMapping.
Before diving too deep into this, I was wondering if anyone here knows why this happens.
1 Like
hello @bashir i see your setting up ref app 2.11.0, not sure why?..but you can try with 2.10 which is the latest stable release and see if you run into the same errors
2 Likes
Can you also try sharing the whole error log, However upgrading spring 5 and hibernate 5 led to removing defaultAnnotationHandlerMapping packages, have a look at how it was done here
1 Like
That is no problem at all. In fact it is highly recommended for developers, for it gives us more testing rounds. 
3 Likes
@bashir i have just run the exact same command and am able to log in the refapp. You may need to share your log as advised above.
2 Likes
Thanks @dkayiwa for trying this; it is good to know that it is working for you, so there is something wrong with my environment.
It seems that, Spring is loading an old version of openmrs-servlet.xml, which is odd because I can confirm that openmrs-servlet.xml that is in the openmrs-web-2.4.0-SNAPSHOT.jar of the war file, is the newest version and for example ParameterMethodNameResolver or DefaultAnnotationHandlerMapping are not referenced in it.
Let me dig a little more into this and I will report back later.
1 Like