[SOLVED] NoSuchBeanDefinitionException when using @OpenmrsProfile

Hi all,

I am trying to make our VDUI module compatible across various versions of the Core/Platform. I started from this article: ‘Supporting different OpenMRS versions’ and copied the logic from openmrs-module-htmlformentry.

So I have this one interface ComplexDataHelper that should be injected with bespoke implementations depending on the Core/Platform version being pre or post 2.0:

Right now there is only one place where an instance of this interface is created, it is as a protected member of another component that until then could be loaded just fine:

@Component(VisitDocumentsConstants.MODULE_CONTEXT_QUALIFIER)
public class VisitDocumentsContext extends ModuleProperties
{
  ...
  protected ComplexDataHelper complexDataHelper = Context.getRegisteredComponent("visitdocumentsui.ComplexDataHelper", ComplexDataHelper.class);
  ... 
}

The above instantiation is what produces the NoSuchBeanDefinitionException upon loading the module:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'visitdocumentsui.ComplexDataHelper' is defined

Here is the full stack trace. This happens when loading the module with the Ref App 2.3 so with Core 1.11.4, which is also the version specified in the main POM.

Any help would be greatly appreciated. Cc: @raff, @dkayiwa, @darius Thanks Daniel for starting to look into it yesterday already on IRC.

P.S. Additionally a context sensitive test also breaks. So if anyone attempts to clone and build the above branch, better to skip tests for now.

This specific error goes away when I upgrade the min 1.10.x version to 1.10.2 in the @OpenmrsProfile annotation of the compatibility implementation class. From 1.10.2 on, openmrsPlatformVersion can be used instead of the deprecated openmrsVersion. This seems to be what was causing the bean loading issue… So

@OpenmrsProfile(openmrsPlatformVersion = "1.10.2 - 1.12.*")

instead of

@OpenmrsProfile(openmrsVersion = "1.10.0 - 1.12.*")

@dkayiwa, please see below. This is running on Core 1.11.4 with Ref App distro 2.3, except for EMR API set to 1.12.


I have to pull back for now on what I said earlier in this thread, I am still running on the same issue:

org.springframework.beans.factory.NoSuchBeanDefinitionException: No bean named 'visitdocumentsui.ComplexDataHelper' is defined

Here is the complete error log.

It is pointing to this line in AbstractDocumentHandler (that in fact is extended by the log mentioned DefaultDocumentHandler):

complexDataHelper = Context.getRegisteredComponent("visitdocumentsui.ComplexDataHelper", ComplexDataHelper.class);

Two things:

  1. Replace the Context.getRegisteredComponent() calls with @Autowired for private ComplexDataHelper complexDataHelper;

  2. These calls are in the api sub project which does not have any implementation of ComplexDataHelper. So you need to have at least one implementation of it in the api sub project if you want the moduleApplicationContext to load it.

1 Like

Hi @dkayiwa,

Ok I did 1) and 2) and this solves all the issues when running on Core 1.11.x (1.11.4 to be precise). However I keep getting the issue on Platform 2.0.1 (SNAPSHOT Build d96a16):

org.springframework.beans.factory.NoSuchBeanDefinitionException:
No qualifying bean of type [org.openmrs.module.visitdocumentsui.obs.ComplexDataHelper] found for dependency: expected at least 1 bean which qualifies as autowire candidate for this dependency.
Dependency annotations: {@org.springframework.beans.factory.annotation.Autowired(required=true), @org.springframework.beans.factory.annotation.Qualifier(value=visitdocumentsui.ComplexDataHelper)}

Everything is updated on https://github.com/mekomsolutions/openmrs-module-visitdocumentsui/tree/MRSDOC-49

In the pom.xml of your omod sub project, did you include a dependency for artifact: ${project.parent.artifactId}-api-2.0?

1 Like

Great! Indeed, the OMOD needs to depend on the additional API subfolder:

<dependency>
  <groupId>${project.parent.groupId}</groupId>
  <artifactId>${project.parent.artifactId}-api-2.0</artifactId>
  <version>${project.parent.version}</version>
</dependency>

It’s working now, thank you!

@dkayiwa, I’m running on this one again, after shuffling around quite a lot of things with the 2.x side of my module… Everything runs fine with Core 1.11.x (Ref App 2.3), but here is what I get when I attempt to install it on Ref App 2.5.

To give some background, there are two build profiles:

  1. Profile ‘1.x’ for JDK < 1.8
  2. Profile ‘2.x’ for JDK = 1.8

Everything is building fine, with both profiles (and so against both JDK). The general idea is that

  • omod-2.0 depends on api-2.0.
  • omod depends on omod-2.0 and api-2.0 (but only under the ‘2.x’ build profile, otherwise not).

This is the branch you could look at: ca07897b8d.

What is the exact platform version that you are using?

Thanks @dkayiwa for clarifying things about POMs setup yesterday on IRC. I was just doing some mis-packaging… all good now.