Investigating InitializationFilter & Installation Wizard Issues – Request for Input

Hi everyone,

Over the past week, I’ve been digging into the InitializationFilter, the very first filter processed when OpenMRS starts for the very first time. My goal is to identify any inconsistencies or potential improvements in this part of the code, particularly as a way to help resolve some of the long-standing issues we’ve seen around the Installation Wizard.


One of the key issues I’ve observed: Sometimes, even when a correct MySQL root password is provided, the database connection still fails, resulting in errors like: Access denied for user 'root'@'localhost' (using password: NO) which usually means that the application is trying to connect to MySQL without providing a password at all, possibly because the password is missing or not being picked up from the configuration properly. OR Access denied for user 'root'@'localhost' (using password: YES)which indicates that a password was provided, but it’s either incorrect or the root user is not allowed to connect from localhost with the given credentials. This is straight forward and likely not an issue.

In both cases, it’s worth checking:

  • If the password is correctly set in the runtime.properties or installation wizard input.
  • If MySQL is configured to allow the root user to connect from localhost.
  • Anything else interfering with this process? I am yet to figure that out but i hope to do so in the foreseeable future.

Some of the improvements i have in mind

I’d love your input on: Any other issues or pain points you’ve encountered during the installation process. Your experiences, suggestions, or even frustrations are all welcome here. The more context we have, the better we can improve this experience for everyone.


cc: @grace @dkayiwa @ibacher @veronica @wikumc @dev5 @dev4 @dev3 @dev2 @dev1 and all implementators out there.

Take care, Herman

5 Likes

I’ve encountered this error a few times as well. I was able to work around it by using incognito mode or switching to a different browser, so can this be related to the browser session, possibly cookies, or cached data?

That said, improving the overall setup experience would be valuable. Best of luck with it, @mherman22!

1 Like

Thanks for sharing your experience. It turns out the issue is related to browser session caching and autofill behavior. When the browser caches an empty or incorrect password, it sometimes submits a blank password field without you realizing it. That’s why using incognito mode or switching browsers temporarily fixes it.

I am hoping to solve this by doing the following:-

  • Setting autocomplete="new-password" on the password field to prevent old values from autofilling.
  • Adding backend validation to catch empty passwords safely even if the browser misbehaves.

These changes should make the setup experience much more reliable without depending on clearing the browser cache. Thanks again for the encouragement. I’m working to get this fixed properly!

2 Likes

Hey @dkayiwa @ibacher i am trying to rewrite openmrs-core/web/src/main/resources/org/openmrs/web/filter/startuperror/coremoduleerror.vm at master · openmrs/openmrs-core · GitHub as part of the pull request attached in this thread.

My challenge is that i am struggling to test the changes in that file, to test them i need to setup a server and make sure one of the core modules is not starting then the StartupErrorFilter will pick it up and render the coremoduleerror template.

what are the core modules that would cause the filter to render that template? i have tried disabling appui, uiframework, rest, fhir2, coreapps but none of them is picked up by that exception (OpenmrsCoreModuleException).

Currently, that’s not a concept we’re using. Core modules used to be set like this (note that there’s only one), but we removed it 11 years ago without removing all the infrastructure around core modules.

I guess you could manually add something to that registry if you really want, but I’m more inclined to open a ticket to remove all vestiges of the “core modules” concept.

Thank you for clarifying, I guess leaving the coremoduleerror.vm unchanged is ideal for that pull request.

Ticket created at Remove all vestiges of the core modules concept. I will cycle back to it in a few.

1 Like

Thanks @mherman22!

One thing I’d like to request is for the InitializationFilter to respect system and java environment variables for automated setup.

Currently, we need to create an install script file to instruct the wizard, but this shouldn’t be needed. Instead we should be loading properties with Spring. See https://www.baeldung.com/properties-with-spring

With property source we should be able to provide any property via openmrs-runtime.properties file or system property or java environment variable. I’ve created an issue for that: TRUNK-6334

For backwards compatibility we still need to support installation script for some time…

1 Like

Thanks @raff for the input.

Definitely makes sense.

Hey @raff,

Since InitializationFilter is currently a servlet filter initialized by the servlet container (and not managed by Spring), it cannot directly use @PropertySource or Spring’s environment. (correct me)

Part of this commit, i am manually loading system properties, environment variables, and installation script properties in that order of precedence inside the filter.

Would you like me to proceed further and explore refactoring InitializationFilter to be a Spring managed bean, allowing us to load properties more cleanly using Spring’s environment abstraction? Or should we keep the current approach for now to maintain minimal changes?

cc: @dkayiwa @ibacher

The minimal changes you made are good. I’d just define the PropertySource for the use in core as part of the issue without using it in InitializationFilter, if that’s too hacky.

1 Like

Hey @raff @dkayiwa

I added the PropertySourcesPlaceholderConfigurer as a bean, and to ensure that ${OPENMRS_APPLICATION_DATA_DIRECTORY}/openmrs-runtime.properties is available when the Spring test context initializes, I registered OpenmrsRuntimePropertiesInitializer via the @ContextConfiguration initializer attribute in BaseContextSensitiveTest.

All this can be seen in this commit TRUNK-6334: Define PropertySource so properties can be specified via property file or system property by mherman22 · Pull Request #5022 · openmrs/openmrs-core · GitHub

However, this has led me to this failure when i run all the tests within web/, any pointers on this?

or is there a better way to ensure the runtime properties are available early enough during test context setup?

Could you please update the PR with the latest changes so I can run it locally?

Updated, thanks!