Investigating InitializationFilter & Installation Wizard Issues – Request for Input

Development
, , , ,
1

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
2

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
3

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
4

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).

5

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.

6

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
7

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
8

Thanks @raff for the input.

Definitely makes sense.