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, 
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 .
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
@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
<dependency>
<groupId>org.openmrs.module</groupId>
<artifactId>emrapi-api</artifactId>
</dependency>
which has a class ,that tries to autowire a bean in emra-api-1.12
<dependency>
<groupId>org.openmrs.module</groupId>
<artifactId>emrapi-api-1.12</artifactId>
<version>${emrapiVersion}</version>
<scope>provided</scope>
</dependency
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.
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.2part 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