Hi folks,
I am now working on a test of the Spring Boot addon setup command. I was
really happy with the changes that you did in the Forge test infrastructure
that allow avoiding listing all the addons that my command depends on in
the @AddonDependencies annotation as well as repeating some of them in the
deployment method body. I was finally able to write tests like that
<
https://github.com/forge/core/blob/master/javaee/tests/src/test/java/org/...
:
@Deployment
@AddonDependencies
public static AddonArchive getDeployment()
{
return ShrinkWrap
.create(AddonArchive.class)
.addBeansXML()
.addClass(ProjectHelper.class)
.addClass(AbstractSecurityCommandTest.class);
}
So I tried the same thing with the Spring Boot addon
<
https://github.com/bgjug/spring-boot-forge-addon> that we started
developing in our JUG. However the test failed. I have attached both the
test and the whole log file. I will here just paste the exception that
stands out:
Caused by: java.lang.LinkageError: loader constraint violation: when
resolving overridden method
"org.jboss.forge.addon.springboot.ui.SpringBootSetupCommand.getProjectFactory()Lorg/jboss/forge/addon/projects/ProjectFactory;"
the class loader (instance of org/jboss/modules/ModuleClassLoader) of the
current class, org/jboss/forge/addon/springboot/ui/SpringBootSetupCommand,
and its superclass loader (instance of
org/jboss/modules/ModuleClassLoader), have different Class objects for the
type
tupCommand.getProjectFactory()Lorg/jboss/forge/addon/projects/ProjectFactory;
used in the signature
at java.lang.Class.getDeclaredMethods0(Native Method)
at java.lang.Class.privateGetDeclaredMethods(Class.java:2615)
at java.lang.Class.getDeclaredMethods(Class.java:1860)
at java.lang.Class.getEnclosingMethod(Class.java:937)
at
org.jboss.weld.util.reflection.Reflections.isNonStaticInnerClass(Reflections.java:401)
at
org.jboss.weld.util.Beans.isTypeManagedBeanOrDecoratorOrInterceptor(Beans.java:492)
at
org.jboss.weld.bootstrap.BeanDeployer.createClassBean(BeanDeployer.java:213)
at
org.jboss.weld.bootstrap.BeanDeployer.createClassBeans(BeanDeployer.java:191)
at
org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:262)
at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:373)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:134)
at
org.jboss.forge.furnace.container.cdi.lifecycle.WeldAddonLifecycleProvider.start(WeldAddonLifecycleProvider.java:77)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable$2.call(AddonRunnable.java:92)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable$2.call(AddonRunnable.java:86)
at org.jboss.forge.furnace.util.ClassLoaders.executeIn(ClassLoaders.java:42)
at
org.jboss.forge.furnace.impl.addons.AddonRunnable.run(AddonRunnable.java:85)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
What I see different between the spring boot addon and the java ee addon,
where the referenced test belongs to, is that our addon has its pom.xml
dependencies in *provided* scope.
Is that the possible cause? Would you please give us advise how to write
tests outside the core addons?
Thanks and regards,
Ivan