-
Bug
-
Resolution: Done
-
Major
-
2.0.0.Alpha4
-
None
In javaee-tests, if you remove the @Ignore from the test test.org.jboss.forge.javaee.servlet.ServletFacetTest.testWebXMLCreatedWhenInstalled() you get the following exception:
Caused by: java.lang.LinkageError: loader constraint violation: loader (instance of org/jboss/modules/ModuleClassLoader) previously initiated loading for a different type with name "org/jboss/shrinkwrap/descriptor/api/webapp30/WebAppDescriptor" at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:422) at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:260) at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:75) at org.jboss.modules.Module.loadModuleClass(Module.java:528) at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:188) at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:444) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:432) at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:399) at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:374) at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:119) at test.org.jboss.forge.javaee.servlet.ServletFacetTest.testWebXMLCreatedWhenInstalled(ServletFacetTest.java:63) ... 88 more
[FORGE-908] LinkageError while using ShrinkWrap classes in Arquillian
Ondrej Zizka (Inactive)
added a comment - Could you please extend the documentation with Do's & Don'ts with how to prevent this? Thx
Ondrej Zizka (Inactive)
added a comment - Could you please extend the documentation with Do's & Don'ts with how to prevent this? Thx 
Lincoln Baxter III (Inactive)
added a comment - Fixed by removing shrinkwrap descriptor API classes from auxiliary archives. This may become a problem again later if additional classes are in conflict, but the temporary solution lies in this approach:
public class ForgeAuxiliaryArchiveProcessor implements AuxiliaryArchiveProcessor { @Override public void process(Archive<?> archive) { if ("arquillian-core.jar".equals(archive.getName())) { Node node = archive.get("org/jboss/shrinkwrap/descriptor"); if (node != null) archive.delete(node.getPath()); } } }
Registered in:
public class ForgeLoadableExtension implements LoadableExtension { @Override public void register(ExtensionBuilder builder) { builder.service(DeployableContainer.class, ForgeDeployableContainer.class); builder.service(DeploymentScenarioGenerator.class, ForgeDeploymentScenarioGenerator.class); builder.service(Protocol.class, ForgeProtocol.class); builder.service(AuxiliaryArchiveProcessor.class, ForgeAuxiliaryArchiveProcessor.class); } }
The ultimate solution would be to implement addons that provide the required test-classes, on which the deployed addons would depend, thus eliminating the duplicate class definition problem altogether, while still leaving the classes available for use.
Lincoln Baxter III (Inactive)
added a comment - Fixed by removing shrinkwrap descriptor API classes from auxiliary archives. This may become a problem again later if additional classes are in conflict, but the temporary solution lies in this approach:
public class ForgeAuxiliaryArchiveProcessor implements AuxiliaryArchiveProcessor
{
@Override
public void process(Archive<?> archive)
{
if ( "arquillian-core.jar" .equals(archive.getName()))
{
Node node = archive.get( "org/jboss/shrinkwrap/descriptor" );
if (node != null )
archive.delete(node.getPath());
}
}
}
Registered in:
public class ForgeLoadableExtension implements LoadableExtension
{
@Override
public void register(ExtensionBuilder builder)
{
builder.service(DeployableContainer.class, ForgeDeployableContainer.class);
builder.service(DeploymentScenarioGenerator.class, ForgeDeploymentScenarioGenerator.class);
builder.service(Protocol.class, ForgeProtocol.class);
builder.service(AuxiliaryArchiveProcessor.class, ForgeAuxiliaryArchiveProcessor.class);
}
}
The ultimate solution would be to implement addons that provide the required test-classes, on which the deployed addons would depend, thus eliminating the duplicate class definition problem altogether, while still leaving the classes available for use. 
This was an internal bug that was fixed in Forge. The way to avoid this is "don't import any additional copies of shrinkwrap or arquillian into the test case"