[SOLVED] java.lang.ClassCastException: AdminList cannot be cast to org.openmrs.module.Extension

Hi all,

I am following up from my last thread:

I am running into another error when loading/starting the module:

java.lang.ClassCastException: org.openmrs.module.visitdocumentsui.extension.html.AdminList cannot be cast to org.openmrs.module.Extension

Here is the full error log, there is not much though…

Our module used to load fine before the refactoring that adds folders api-1.11 and api-2.0. In particular I have not touched the class AdminList (actually it is still the default one generated by the SDK when I created the module with it).

I also tried to remove AdminList and its reference in config.xml altogether but that leaves me with a similar error:

java.lang.ClassCastException: org.openmrs.module.visitdocumentsui.VisitDocumentsActivator cannot be cast to org.openmrs.module.Activator

I’m going to keep comparing our module to openmrs-module-htmlformentry as this was the model for the current work, but otherwise any directions would be really welcome. At this point I am not really sure where to look anymore.

Cc: @raff, @darius

P.S. This will be the subject of another thread but tests are also broken because of the above work. This means that builds of the branch in question should currently be run with -Dmaven.test.skip=true, for those eager to look :wink:

On which version of the platform are you running this module? And are you running in debug or dev mode? Can we look at the compiled omod?

On which version of the platform are you running this module?


And are you running in debug or dev mode?

I am not entirely sure about what you mean here. I am using the SDK to launch its embedded Tomcat with the following command:

mvn openmrs-sdk:run -Dport=8080 -Ddebug=58080 -DserverId=dev_2_3

Does that make it debug?

Can we look at the compiled omod?

Yes however please note - and that is part of something I wanted to look into after closing this thread - that through the changes that I am currently implementing and that are described in my two last topics, this OMOD went from 1MB to 54MB (!) Perhaps is it therefore easier for you to clone and build (with -Dmaven.test.skip=true)? I have made sure that our module builds on a blank .m2 by removing my dependency on the refapp distro as per our IRC discussion.

The branch to clone is here btw: https://github.com/mekomsolutions/openmrs-module-visitdocumentsui/tree/MRSDOC-49

I see that a big number of your pom dependencies miss scope provided. This leads to your compiled module’s lib folder being too big. Can you fix it by adding the provided scope to all dependencies that come from the core platform and other modules? This is also the most common cause of your particular ClassCastException where you have the same class loaded from different jars in the class path. Tell us what happens after doing the needful.

1 Like

Ah, great, thanks Daniel. Indeed, I could shrink the size down back to 2.7MB and the above exception went away. I am still running onto bean creation issues, I will report in the original thread and mention you there.