LinkageError on application startup with Axon included in dependency

We have a number of services that all share a single service template as a dependency. We would like to include our Axon configuration in this dependency but on startup this is giving us a java.lang.LinkageError (in 15 years I think this is the first time that I’ve seen this error). The only solution that we have found is to remove Axon completely from our child project.

Stack trace follows

`

Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of sun/misc/Launcher$AppClassLoader) previously initiated loading for a different type with name “org/axonframework/commandhandling/SimpleCommandBus”
at java.lang.ClassLoader.defineClass1(Native Method) ~[?:1.8.0_181]
at java.lang.ClassLoader.defineClass(ClassLoader.java:763) ~[?:1.8.0_181]
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) ~[?:1.8.0_181]
at java.net.URLClassLoader.defineClass(URLClassLoader.java:467) ~[?:1.8.0_181]
at java.net.URLClassLoader.access$100(URLClassLoader.java:73) ~[?:1.8.0_181]
at java.net.URLClassLoader$1.run(URLClassLoader.java:368) ~[?:1.8.0_181]
at java.net.URLClassLoader$1.run(URLClassLoader.java:362) ~[?:1.8.0_181]
at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_181]
at java.net.URLClassLoader.findClass(URLClassLoader.java:361) ~[?:1.8.0_181]
at java.lang.ClassLoader.loadClass(ClassLoader.java:424) ~[?:1.8.0_181]
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) ~[?:1.8.0_181]
at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ~[?:1.8.0_181]
at com.capitalone.base.config.RoboAxonFactory.registerMetaDataInterceptors(RoboAxonFactory.java:24) ~[axon-bug-child-0.0.3.jar:?]
at com.capitalone.customer.config.AxonConfiguration.registerMetaDataInterceptors(AxonConfiguration.java:28) ~[classes/:?]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[?:1.8.0_181]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[?:1.8.0_181]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[?:1.8.0_181]
at java.lang.reflect.Method.invoke(Method.java:498) ~[?:1.8.0_181]
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor$AutowiredMethodElement.inject(AutowiredAnnotationBeanPostProcessor.java:699) ~[spring-beans-5.0.7.RELEASE.jar:5.0.7.RELEASE]
at org.springframework.beans.factory.annotation.InjectionMetadata.inject(InjectionMetadata.java:91) ~[spring-beans-5.0.7.RELEASE.jar:5.0.7.RELEASE]
at org.springframework.beans.factory.annotation.AutowiredAnnotationBeanPostProcessor.postProcessPropertyValues(AutowiredAnnotationBeanPostProcessor.java:373)

`

My dependency tree looks somthing like:

`
±-- com.capitalone.customer:linkage-error-bug-parent:0.0.3

±-- com.capitalone.base:linkage-error-bug-child:0.0.3

-– org.axonframework:axon-spring-boot-starter:3.3.2

… …

`

Has anyone seen anything like this before?

Thanks!
Dave Garred

Do you have 2 versions of Axon on the classpath? It looks like 2 different class loaders are trying to load a different version of the same class.

Allard

PS. Removing Axon is never a solution :wink:

Negative. Confirmed that even after pulling out the Axon test dependencies from the parent package I’m running into this.

Does your module link to native code?

Hi Dave,

I’d be really surprised if this is Axon related, especially since there’s a spring-boot entry in the stack trace. Spring boot is notorious for messing with the class path in really unexpected ways (e.g. fat-jar builds, jars-within-jars and all the joys that come with that.)

A quick search for “spring boot” and LinkageErrors confirms that you’re not the only one struggling with this. From what I’ve seen, this may be caused by the Spring Boot dev tools (often turned on automatically by STS/Intellij). Apparently there’s a mechanism to support hot class reloading – that’d be my guess.

Does this reproduce when not running from within the IDE/Junit launcher? Can you confirm if dev-tools or other funky JVM/spring boot parameters are turned on and if the issue persists with that disabled?

Cheers,
Patrick

https://github.com/spring-projects/spring-boot/issues/3316#issuecomment-148731640The discussion references two additional related issues as well.

Workaround is apparently to setup/modify the “META-INF/spring-devtools.properties” file to un-screw the class path:
https://docs.spring.io/spring-boot/docs/current/reference/html/using-boot-devtools.html#using-boot-devtools-customizing-classload

~Patrick

Hi Patrick,

Good to hear from you, hope you’re doing well. Once again you nailed it.

We had a runtime dependency on a spring-boot-devtools package that seems to be the culprit. Removing this cleared up the problem straight away.

Looks like this package is trying to help with reloading of classes at runtime, once again Spring magic making a giant problem out of a minor inconvenience.

Note that the problem did occur even outside of the IDE, same problem with running it directly (note that it is a Spring Boot project though).

Dave