Injecting MyModuleProperties in a controller causes hang

Hi all,

I’ve been stumbling on a quite blocking situation. On the model of what is done in Core Apps, I created a ModuleProperties class for my module:

import org.openmrs.module.emrapi.utils.ModuleProperties;

public class MyModuleProperties extends ModuleProperties {

But when I install my module with this class being injected in some controller:

public class MyController {
  public void controller(..., @SpringBean("myModuleProperties") MyModuleProperties properties, ...) {

then everything just hangs at

WARN - DisposableBeanAdapter.destroy(247) |2016-04-22 12:02:16,022| Invocation of destroy method failed on bean with name 'sessionFactory':
org.hibernate.cache.CacheException: java.lang.IllegalStateException: The CacheManager has been shut down. It can no longer be used.

And the only way to get out of that situation is to actually kill the Java process! The whole thing is just dead-blocked…

I thought I may have to define something either in omod’s webModuleApplicationContext.xml or api’s moduleApplicationContext.xml, but looking at Core Apps as an example I can see that this is not the case. (There doesn’t seem to be anything either in config.xml about this properties class.)

I really don’t see what I am missing versus what is done in Core Apps, could anyone help me out?

Does it still hang if you remove the @Controller annotation from your controller?

Yes, this makes no difference.

It is possible to look at your MyModuleProperties and the full controller?

If it is ok for you to pull this branch: everything is here. What I committed would let the module build, but the installation would hang. That is with platform 1.11.4 and distro 2.3.

@dkayiwa, did you have a chance to build this and have a look?

I get some compiler errors like: Failure to find org.openmrs.distro:referenceapplication:pom:2.3-SNAPSHOT Do you have a branch that would just compile without requiring me to first resolve any errors?

Indeed, although I was very careful at depending only on distro 2.3, some dead dependencies on distro 2.3-SNAPSHOT came further down the line (and out of my will, consent & control). As you can imagine, it was working locally for me because of .m2 keeping it all in store, making me oblivious that I was probably one of the few people in the world still able to build my legit looking POM (unsurprisingly the issue comes from emrapi-api…)

So I made it all depend on 2.4-SNAPSHOT and it works. For now… If you don’t mind pulling again… the tmp branch here.

Thank you.

@mksd add either a require_module or aware_of_module for the emrapi and test again.

1 Like

Yes, thank you! I missed that one from Core Apps’s config.xml:

  <require_module version="${emrapiVersion}">