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. ORAccess 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.
Improving step navigation , so users can jump back to previous steps if needed in order to tweak something.
Improving the progress indicator: currently it hangs at 99% for quite a while during the “big context refresh” when modules are loading. It might be better to replace this with a clearer “loading” indicator.
How we can provide better feedback when modules fail to start (currently, the alert for the admin user isn’t as helpful as it could be).
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.
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!
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!
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.
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…
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?
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.
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.