RA-1714: No qualifying bean of type 'org.openmrs.module.emrapi.diagnosis.DiagnosisService Error

while working on https://issues.openmrs.org/browse/RA-1714 , i want to use getDiagnoses(Encounter encounter) method so as to return a list of Diagnoses in an encounter,i introduce a sub module called coreapps-web-2.2 in core apps module ,as seen RA-1714:Primary Diagnosis not being showed in the Encounter details by HerbertYiga · Pull Request #377 · openmrs/openmrs-module-coreapps · GitHub and this has changes that depend on core 2.5.0-SNAPSHOT as seen These changes are depended on by RA-1714 by HerbertYiga · Pull Request #3682 · openmrs/openmrs-core · GitHub Looking through the introduced submoudle,i have a class called DiagnosisServiceCompatibility2_2Test that i use to test a method from DiagnosisServiceCompatibility interface,my tests break with a no qualifying bean error as per the logs java.lang.IllegalStateException: Failed to load ApplicationContext at org.spri - Pastebin.com i did some work around on changing versions of different dependencies within the pom of my sub module,but this didn’t help much since my dependencies seem to load well,i have read some articals around suggesting to use autowire annotation on accessing services from the api within my submodule,still this didn’t help ,been blocked for some days, :grin: :grin:any thoughts on fixing this cc @dkayiwa @mksd @mksrom @ibacher @mozzy @burke @mogoodrich

Sorry about the error , but the standard way to acces OpenMRS services is through the Context(ServiceContext) , not AutoWiring them .

1 Like

by the way i run into the same error even on using the Context

Are these the right logs ??

how comes the Logs containg emrapi not openmrscore
No qualifying bean of type 'org.openmrs.module.emrapi.diagnosis.DiagnosisService available

those are the right logs after running the submodule i created in core apps

First try to Acces it through the Context , and we debug that

ok,let me do and drop the logs here

I don’t know that we can say that it’s a standard way. It’s sometimes the only way, for instance in an activator or a REST WS resource as none are beans themselves.

The static Context in general is an antipattern btw, it’s not in itself standard by any means.

It should be fine to autowire services when inside a bean, which is - I think - @herbert24’s situation with his conditional compatibility bean.


these are the logs java.lang.IllegalStateException: Failed to load ApplicationContext at org.spri - Pastebin.com

Makes sense @mksd ,

But for @herbert24 case , he is autowiring inside a non-bean

@mozzy to my understanding i thought as long as you have the core dependencies in the pom of a sub module,you should be fine with auto wiring or accessing services via context

It seems like the error is not around the Core services you Autowired or accessed through Context ,

The problem is with your emr-api depencies. example ,

Iny our submodule , you only added a emrapi-api dependence


which has a class ,that tries to autowire a bean in emra-api-1.12


please explicitly add the other depencies of emrapi sub-modules

For example your tests run against core 2.5.* and the observationMapper bean in emrapi-api autowired in the EncounterObservationsMapper emrapi-api is only loaded for these OpenMRs Versions 1.9.* - 1.11.*
meaning the actual bean to be loaded for OpenMRSverions 2.* is in emr-api-1.12 which you ddnt add into your sub-module.

1 Like

thanks mosses let me get here after trying out the suggestions you dropped me

A couple of remarks here:

  • If you’re depending on changes that are in 2.5, the work should be done in a module like web-2.5.
  • I would substantially trim the modules that you are loading in your new coreapps-web-2.2 part to only those that you actually require. I.e., why are you even depending on EMRAPI here?

point noted

well before having the emrapi dependencies, my tests break, am going to first remove the emrapi dependency and drop the logs here

well i got to see this,i donot really need the emrapi module @ibacher

1 Like