GSOC 2025: Replacing OpenMRS Standalone with a Modern, User-Friendly Alternative - Updates and Discussion

Just seen here

As a result of this work, we should have a standalone distribution for OpenMRS 2.x (latest snapshot), OpenMRS 3.x, and the OpenMRS Core Platform (2.7.x and 2.8.x).

this confirms that the standalone is expected to run 2.x for the latest snapshot 2.14.0-SNAPSHOT which supports java 17 if not mistaken :upside_down_face:

cc @dkayiwa @wikumc

yes, 2.14.0-SNAPSHOT is running on openmrs-distro-referenceapplication/pom.xml at 73af5bec8d3af6436dc723898a4eace8140b8f8d · openmrs/openmrs-distro-referenceapplication · GitHub which supports 17 as seen at openmrs-core/pom.xml at 00f89f70d5ff3f2ca48429de3545c5b9f3bee4a3 · openmrs/openmrs-core · GitHub

1 Like

makes sense @mherman22 let me build it and see how it goes gonna update here in a few :face_savoring_food:

@mherman22 have u ever experienced this before INFO - StorageServiceCondition.matches(38) |2025-07-03T12:31:31,663| Selected st - Pastebin.com

Am getting this error via standalone though working fine on sdk

for more context this is my openmrs-runtime.properties

#Last updated by the OpenMRS Standalone application.
#Thu Jul 03 12:31:21 EAT 2025
module.allow_web_admin=true
vm_arguments=-Xmx512m -Xms512m -XX:NewSize=128m --add-exports=java.desktop/com.apple.eawt=ALL-UNNAMED
connection.password=dDaJ80MlV4kZ
application_data_directory=appdata
connection.database.data_dir=./database/data
connection.username=openmrs
connection.url=jdbc:mysql://127.0.0.1:3316/openmrs?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull
auto_update_database=false
tomcatport=8081

cc @dkayiwa @wikumc

Hard to tell without a server side log.

full log can be found here Attempting to load properties file in current directory: openmrs-runtime.propert - Pastebin.com

I think spring is expecting a property named OPENMRS_APPLICATION_DATA_DIRECTORY, but it’s not set. You must make sure OPENMRS_APPLICATION_DATA_DIRECTORY is available to Spring before the context is initialized. You cannot rely on openmrs-runtime.properties to define that value, because it’s used to locate that file.

This bean openmrs-core/api/src/main/resources/applicationContext-service.xml at 00f89f70d5ff3f2ca48429de3545c5b9f3bee4a3 · openmrs/openmrs-core · GitHub is the culprit

This should not be a requirement and this looks like someone made a broken assumption in core. More specifically, OPENMRS_APPLICATION_DATA_DIRECTORY has always been an optional system property that could be used to provide a default, but is not required. If the Spring configuration is now requiring that be set, that’s a breaking change and needs to be undone.

Two notes I’ll make here:

  1. We currently have two PropertySourcesPlaceholderConfigurer beans defined in applicationContext-service.xml that reference this value and seem to just duplicate one another.
  2. Rather than relying on the property being set, we should be able to create the PropertySourcesPlaceholderConfigurer programmatically, so that instead of relying on the property, we can call the usual OpenmrsUtil.getApplicationDataDirectory() call.
3 Likes

@mherman22 do you think you can look into this?

Yes, looking into it right now. Here is the JIRA ticket to track it Jira

2 Likes

thank u @mherman22 tracing PR here -

cc @dkayiwa @ibacher @wikumc

Hey @jonathan , i have made the changes to fix the issue you reported earlier by making sure spring doesn’t prematurely require OPENMRS_APPLICATION_DATA_DIRECTORY. I have tested this with the sdk, i now want to test with the standalone before pushing in a pullrequest.

Guide me on how to test that with the standalone.

pull the changes on this draft PR STAND-116: Replace the embedded mysql with mariadb4j in Ref App 2.x by Muta-Jonathan · Pull Request #74 · openmrs/openmrs-standalone · GitHub and run

  1. mvn clean
  2. mvn install or mvn package
  3. then copy the referenceapplication-standalone-2.14.0-SNAPSHOT.zip from the target folder and unzip
  4. then run java -jar openmrs-standalone.jar inside the directory

NOTE: this so far works on mac and linux … not on windows

@jonathan can you pull @mherman22’s changes, compile them and test again?

2 Likes

@dkayiwa with these new changes am able to announce that the 2.x ref App on 2.8.0-SNAPSHOT is able to run fine thanks to @mherman22 and @ibacher

Login page

Home Page

Just for confirmation here is the system info

cc @dkayiwa @mherman22 @wikumc

1 Like

Just confirming which concept dictionary you are planning with the standalone and to make sure we have a path to overwrite with an OCL export which includes CIEL/custom concepts managed on OCL online :slight_smile: