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

Community GSoC
,
61

So basically, when we use:

-Drefapp.version=3.4.0

It locates distro-emr-configuration-3.4.0.zip from: JFrog

Downloading from openmrs-repo: https://mavenrepo.openmrs.org/public/org/openmrs/distro-emr-configuration/3.4.0/

However, when we specify:

-Drefapp.version=3.6.0-SNAPSHOT

It is unable to locate distro-emr-configuration-3.6.0-SNAPSHOT.zip because in the location: 3.6.0-SNAPSHOT Location

I see we have:

distro-emr-configuration-3.6.0-20250807.131409-1.zip

with release timestamps included, which makes distro-emr-configuration-3.6.0-SNAPSHOT.zip unavailable. This also happens for other versions that follow similar timestamped SNAPSHOT versioning in their repository folders.

62

@dkayiwa Just made a deep dive and During the build process, I observed that specifying a SNAPSHOT version like:

-Drefapp.version=3.6.0-SNAPSHOT

causes the build to look in: https://openmrs.jfrog.io/ui/native/public/org/openmrs/distro/referenceapplication-distro/.

In contrast, if we use a release version, for example:

-Drefapp.version=3.4.0

it fetches the distribution from: https://openmrs.jfrog.io/ui/native/public/org/openmrs/distro-emr-configuration/.

This behavior is managed internally by the OpenMRS SDK Maven Plugin (org.openmrs.maven.plugins:openmrs-sdk-maven-plugin:6.4.0) with the configuration:

<plugin>
    <groupId>org.openmrs.maven.plugins</groupId>
    <artifactId>openmrs-sdk-maven-plugin</artifactId>
    <version>6.4.0</version>
    <executions>
        <execution>
            <id>build-distro</id>
            <phase>generate-resources</phase>
            <goals>
                <goal>build-distro</goal>
            </goals>
            <configuration>
                <distro>referenceapplication:${refapp.version}</distro>
                <dir>${project.build.directory}/distro</dir>
            </configuration>
        </execution>
    </executions>
</plugin>

For versions like 3.0.0-SNAPSHOT, the build succeeds because the required distro artifact is available in the referenceapplication-distro repository → https://openmrs.jfrog.io/ui/native/public/org/openmrs/distro/referenceapplication-distro/.

I’ve realized that the issue isn’t the timestamped SNAPSHOTs, as I initially thought, but rather that build-distro sometimes fails to locate the artifact, even though mvn openmrs-sdk:setup can resolve it internally.

63

We usually have to run mvn openmrs-sdk:setup-sdk to update the settings.xml file .m2 folder. Did you?

64

Oh yes I specified mine here

And i use mvn install --settings .github/maven-settings.xml

65

So i have looked through your draft pull request and i see the limitation with build-distro, perhaps something we can think about fixing but the workaround i found was to do a two-step execution i.e (generate-distro, then build-distro) where generate-distro creates the openmrs-distro.properties file based off the provided answers using the batchAnswers parameter, then build-distro uses that file to generate the required docker configuration files.

See build when i do that Ubuntu Pastebin

2 Likes
66

great great work @mherman22 thanks for the look up let me test it out :heart_eyes:

67

Really excited about this solution! :tada: The working PR is here:

and the associated ticket is STAND-129: Build-distro fails to resolve SNAPSHOT artifacts while sdk:setup succeeds in 3.x Standalone.

A big thanks to @mherman22 for the quick guidance—it’s much appreciated!

With this fix, I believe the 3.x Standalone is now ready for testing and can be considered for the final 3.5.0 release once we get the green light.

cc: @wikumc @dkayiwa @ruhanga @jayasanka @jwnasambu @dkigen

4 Likes
68

Hi all,

I’m running into an issue when trying to run OpenMRS 3.x Standalone with MariaDB.

When I set my connection URL like this:

connection.url=jdbc:mariadb://127.0.0.1:3316/openmrs?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull

I get the following exception on startup:

java.lang.IllegalStateException: No WebApplicationContext found: no ContextLoaderListener registered?
	at org.springframework.web.context.support.WebApplicationContextUtils.getRequiredWebApplicationContext(WebApplicationContextUtils.java:85)
	at org.springframework.orm.hibernate5.support.OpenSessionInViewFilter.lookupSessionFactory(OpenSessionInViewFilter.java:194)
	at org.springframework.orm.hibernate5.support.OpenSessionInViewFilter.lookupSessionFactory(OpenSessionInViewFilter.java:180)
	at org.springframework.orm.hibernate5.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:131)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
	at org.springframework.web.multipart.support.MultipartFilter.doFilterInternal(MultipartFilter.java:125)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:117)
	at org.openmrs.web.filter.StartupFilter.doFilter(StartupFilter.java:120)
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:201)

Full error trace here: Pastebin link

Observations:

  1. This does not happen when I switch to MySQL instead of MariaDB.
  2. I’m using OpenMRS 2.8.0 libraries inside 3.x standalone.
  3. On server restart, OpenMRS cannot connect to the database and redirects to the installer, trying to create a new instance.
  4. I also tried specifying:
hibernate.dialect=org.hibernate.dialect.MariaDBDialect

in openmrs-runtime.properties, but the same result occurs.

  1. This setup was intended to solve:
java.sql.SQLSyntaxErrorException: Unknown column 'RESERVED' in 'WHERE'

The commit by @raff adding MariaDB support for replication/failover might be related: Commit link

Questions:

  • Has anyone else seen this No WebApplicationContext found error when using MariaDB in 3.x standalone?
  • Is this an incompatibility with the 2.8.x OpenMRS core libraries and MariaDB?
  • Could there be a missing configuration step for the MariaDB driver to work correctly with OpenMRS 3.x?

cc @dkayiwa, @wikumc @ian, @raff

Any guidance would be appreciated!

For a checkout Kindly take a look by changing the connection.url in openmrs-runtime.properties here openmrs-standalone/src/main/config/openmrs-runtime.properties at e4c0929f8e14fc9b9bb850b31b4486aa9a88e703 · openmrs/openmrs-standalone · GitHub to connection.url=jdbc:mariadb://127.0.0.1:3316/openmrs?autoReconnect=true&useUnicode=true&characterEncoding=UTF-8&zeroDateTimeBehavior=convertToNull

69

Did you change the driver from mysql-connector-java to mariadb-java-client in the standalone?

70

Yes, I did. I switched from mysql-connector-java to mariadb-java-client in the standalone by adding the following dependency:

<dependency>
    <groupId>org.mariadb.jdbc</groupId>
    <artifactId>mariadb-java-client</artifactId>
    <version>3.5.4</version>
    <scope>compile</scope>
</dependency>

I also updated openmrs-runtime.properties to explicitly use the MariaDB driver:

hibernate.connection.driver_class=org.mariadb.jdbc.Driver
hibernate.dialect=org.hibernate.dialect.MariaDBDialect

And in code, I replaced:

Class.forName("com.mysql.cj.jdbc.Driver").newInstance();

with:

Class.forName("org.mariadb.jdbc.Driver").newInstance();

However, even after making these changes, I was still getting the same error.

71

Can you just raise a pull request with your changes?

72

Sure here is the PR

73

I have just made a commit to openmrs-core. To take advantage of these changes, you will need to compile the standalone with something like mvn package -Dopenmrs.version=2.8.1-SNAPSHOT

74

Wonderful @dkayiwa thanks for the fix … Just tested and works as expected … :melting_face:

I will go ahead and switch version also on the PR to use 2.8.1-SNAPSHOT OpenMRS core version