Initializer fails OpenMRS startup if running emrapi 3.3.0

[mseaton]

We are running the latest initializer snapshot (2.12.0-SNAPSHOT) along with emrapi 3.3.0 and OpenMRS is failing to start, presumably due to 9b8e9ff

The error is:

WARN - AbstractApplicationContext.refresh(591) |2026-06-04T08:35:36,516| Exception encountered during context initialization - cancelling refresh attempt: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'procedureTypesLoader': Unsatisfied dependency expressed through method 'setParser' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'procedureTypesCsvParser': Lookup method resolution failed; nested exception is java.lang.IllegalStateException: Failed to introspect Class [org.openmrs.module.initializer.api.procedure.ProcedureTypesCsvParser] from ClassLoader [{ModuleClassLoader: uid=1250730284; initializer}]
INFO - ServiceContext.doneRefreshingContext(852) |2026-06-04T08:35:36,526| Done refreshing Context
Exception in thread "pool-2-thread-10" Exception in thread "pool-2-thread-7" Exception in thread "pool-2-thread-8" Exception in thread "pool-2-thread-9" Exception in thread "pool-2-thread-3" org.openmrs.module.ModuleException: Unable to run onStartup() method of service {} Module: $Proxy333

This is easily reproducible by just setting up an OpenMRS SDK server using these distro properties below, and starting it up:

name=Iniz Test
version=1.0.0-SNAPSHOT
war.openmrs=2.8.6
omod.addresshierarchy=2.21.0
omod.appframework=2.19.0
omod.appui=1.18.0
omod.authentication=2.3.0
omod.authenticationui=1.3.0
omod.calculation=2.0.0
omod.coreapps=3.4.0
omod.emrapi=3.3.0
omod.event.groupId=org.openmrs
omod.event=4.0.0
omod.fhir2=3.1.0-SNAPSHOT
omod.htmlformentry=7.2.1
omod.htmlformentryui=3.2.0
omod.htmlwidgets=2.0.1
omod.idgen=5.0.4
omod.initializer=2.12.0-SNAPSHOT
omod.legacyui=2.1.0
omod.metadatadeploy=1.13.0
omod.metadatamapping=2.0.0
omod.metadatasharing=1.10.0
omod.namephonetics=1.19.0
omod.owa=1.15.0
omod.registrationapp=1.29.0
omod.registrationcore=1.13.0
omod.reporting=2.1.0
omod.reportingcompatibility=2.10.0
omod.reportingrest=2.0.0
omod.reportingui=1.14.0
omod.serialization.xstream.type=omod
omod.serialization.xstream=0.3.0
omod.spa=2.1.0
omod.uicommons=3.1.0
omod.uiframework=4.0.0
omod.uilibrary=2.0.7
omod.webservices.rest=3.4.1

property.initializer.startup.load=fail_on_error

db.h2.supported=false

@wikumChamith / @ibacher FYI

[wikumChamith]

PR with the fix: #326

Thanks @ibacher suggesting this during the O3 squad call :)

[ibacher]

So here's what I think is happening here and why this fix works:

@OpenmrsProfile is basically only consumed by the OpenmrsProfileExcludeFilter and the OpenmrsProfileIncludeFilter. In any other context, it is powerless. So basically it triggers in this component scan. Because the OpenmrsProfileIncludeFilter matches anything that is annotated @OpenmrsProfile if it's conditions are met, it effectively acts as if @OpenmrsProfile were annotated with @Component (and this is, in fact, how modern Spring would recommend creating a custom annotation).

When we add the @Component annotation, the component is recognized by the component scan like this one. Because this scan is done without the exclude filter, the @OpenmrsProfile doesn't prevent the bean from loading.

It seems like it's more of a fluke that this happened to raise an error rather than intentionally something well-thought out working well (though, FWIW, I have for years been trying to point out that component-scan elements in modules that use the org.openmrs base package are almost certainly errors for exactly this reason).