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

Community GSoC
,
21

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

22

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
23

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

24

@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

Screenshot from 2025-07-03 12-31-42
Screenshot from 2025-07-03 12-31-421920×1080 231 KB

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

25

Hard to tell without a server side log.

26

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

27

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

28

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
29

@mherman22 do you think you can look into this?

30

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

2 Likes
31

thank u @mherman22 tracing PR here -

cc @dkayiwa @ibacher @wikumc

32

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.

33

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

34

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

2 Likes
35

@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

Screenshot from 2025-07-04 03-58-22
Screenshot from 2025-07-04 03-58-221920×1080 153 KB

Home Page

Screenshot from 2025-07-04 03-58-31
Screenshot from 2025-07-04 03-58-311920×1080 201 KB

Just for confirmation here is the system info

Screenshot from 2025-07-04 04-09-18
Screenshot from 2025-07-04 04-09-181920×1080 287 KB

cc @dkayiwa @mherman22 @wikumc

2 Likes
36

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:

37

@akanter currently for Standalone-Platform we used ciel-dictionary - 2.5.5-20250512

<ciel.dictionary.openmrs.version>2.5.5</ciel.dictionary.openmrs.version>
<ciel.dictionary.version>20250512</ciel.dictionary.version>

Which i presume this has been updated for the last couple of weeks

cc @dkayiwa @wikumc

1 Like
38

Thanks. There is a new version as of June 13, but this is fine. Wanted to be sure there had been no concept table changes between 2.5.5 and the latest framework and no additional non-CIEL concepts are required by the Ref App.

2 Likes
39

cc @dkayiwa @wikumc Do we need to update to the latest ciel.dictionary.version as of June 13 for Standalone Platform (main branch)?

1 Like
40

Yes we should.

2 Likes