Open jurajcik opened 8 years ago
If 1.7.0_79
is your JDK-version, you should upgrade to JDK 1.8, the support for Java SE 7 was discontinued by Oracle. Did you try that already?
Thanks, actually I was originally using JDK 1.8 and only later tried 1.7 just to make sure that the problem ist not in the 1.8. Now I installed the latest version of 1.8 and tried it with that, but the result is in my eyes basically the same:
08:58:35,799 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.deployment.unit."93a64f49-4ce8-4a13-8032-61729aab4e9d.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."93a64f49-4ce8-4a13-8032-61729aab4e9d.war".POST_MODULE: JBAS018733: Failed to process phase POST_MODULE of deployment "93a64f49-4ce8-4a13-8032-61729aab4e9d.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_73]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_73]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_73]
Caused by: java.lang.StackOverflowError
at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java)
at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java)
I have the same issue:
`
Hi, can you provide more details about your environment?
Output from mvn dependecy:tree
would be of a great help. Ideally also how your tests are structured etc.
With these short stacktraces it might be challenging to reproduce the problem.
Hi,
I have the same problem. I attached a test maven project with multiple modules. The "test_integration" module does the integration test for projects "jar_business" and "jar_repositories".
During integration test I got:
Caused by: java.lang.StackOverflowError at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java) test.zip
Thanks @bartatamas for sharing the project, I will have a look.
@bartatamas when I disable JaCoCo extension and run the tests against managed WildFly I'm getting this:
-------------------------------------------------------------------------------
Test set: bt.javaee.ITRepositories
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 29.173 sec <<< FAILURE! - in bt.javaee.ITRepositories
bt.javaee.ITRepositories Time elapsed: 29.173 sec <<< ERROR!
org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy: application.ear
Caused by: java.lang.Exception:
{"JBAS014671: Failed services" => {"jboss.deployment.unit.\"application.ear\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"application.ear\".WeldStartService: Failed to start service
Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied dependencies for type Map<String, String> with qualifiers @Parameters
at injection point [BackedAnnotatedParameter] Parameter 1 of [BackedAnnotatedConstructor] @Inject org.eclipse.sisu.wire.StringProperties(@Parameters Map<Object, Object>)
at org.eclipse.sisu.wire.StringProperties.<init>(StringProperties.java:0)
WELD-001475: The following beans match by type, but none have matching qualifiers:
- Managed Bean [class org.eclipse.sisu.wire.StringProperties] with qualifiers [@Any @Default],
- Producer Method [Map<String, String>] with qualifiers [@BatchProperty @Any] declared as [[UnbackedAnnotatedMethod] @Produces @BatchProperty public org.jberet.creation.BatchBeanProducer.getStringMap(InjectionPoint)]
"}}
The issue is that you are fetching too many dependencies to your project (all from the test scope). This line is not needed unless you really use some test specific libraries which are not bundled by arquillian by default (e.g. assertj
):
// Add test dependencies to it
file[] files = Maven.resolver().loadPomFromFile("pom.xml").importTestDependencies().resolve().withTransitivity().asFile();
ear.addAsLibraries(files);
But after fixing it I'm facing an issue that either DB is not set (which is not surprising as I cannot find anything for setting it up):
I cannot reproduce the problem using your project. Any hints from all the others would be more than appreciated.
Hi,
Sorry, I forget that this project needs database. Interesting, that when I removed the lines you wrote (import test dependencies) then StackOverflowError disappeared. When I put it back, it appears again.
Those lines are not needed - this might actually be the rootcause as we have for example arquillian dependencies added twice to the project I believe. Another point is - you might consider user include/exclude feature (improved in the last release 1.0.0.Alpha9
) to narrow it only to the relevant classes or packages.
i have the same problem with latest version 1.0.0.Alpha9 and jacoco .0.7.8 but i could not delete those lines it send me class not found error
@leccyril could you share your config in the gist?
yes of course
`<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<groupId>com.real</groupId>
<artifactId>RflowHR</artifactId>
<version>0.1-SNAPSHOT</version>
<properties>
<argLine>-Xmx2048m</argLine>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
<version.jboss.spec.javaee.7.0>1.0.3.Final</version.jboss.spec.javaee.7.0>
<default.scope>provided</default.scope>
<test.scope>test</test.scope>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
<repositories>
<repository>
<id>jcenter</id>
<name>bintray</name>
<url>http://jcenter.bintray.com</url>
</repository>
</repositories>
<dependencyManagement>
<dependencies>
<!-- Define the version of the JBoss Java EE APIs we want to import. Any
dependencies from org.jboss.spec will have their version defined by this
BOM -->
<!-- JBoss distributes a complete set of Java EE APIs including a Bill
of Materials (BOM). A BOM specifies the versions of a "stack" (or a collection)
of artifacts. We use this here so that we always get the correct versions
of artifacts. Here we use the jboss-javaee-7.0 stack (you can read this as
the JBoss stack of the Java EE APIs). You can actually use this stack with
any version of WildFly that implements Java EE. -->
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-7.0</artifactId>
<version>${version.jboss.spec.javaee.7.0}</version>
<type>pom</type>
<scope>import</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian</groupId>
<artifactId>arquillian-bom</artifactId>
<version>1.1.12.Final</version>
<scope>import</scope>
<type>pom</type>
</dependency>
</dependencies>
</dependencyManagement>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<configuration>
<source>1.8</source>
<target>1.8</target>
</configuration>
</plugin>
<!--plugin> <groupId>org.mock-server</groupId> <artifactId>mockserver-maven-plugin</artifactId>
<version>3.10.4</version> <configuration> <serverPort>1080</serverPort> <proxyPort>1090</proxyPort>
<logLevel>DEBUG</logLevel> <initializationClass>org.mockserver.maven.ExampleInitializationClass</initializationClass>
</configuration> <executions> <execution> <id>process-test-classes</id> <phase>process-test-classes</phase>
<goals> <goal>start</goal> </goals> </execution> <execution> <id>verify</id>
<phase>verify</phase> <goals> <goal>stop</goal> </goals> </execution> </executions>
</plugin -->
<!--<plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-javadoc-plugin</artifactId>
<version>2.10.4</version> <executions> <execution> <id>attach-javadocs</id>
<goals> <goal>jar</goal> </goals> <configuration> <sourcepath>src/main/java/</sourcepath>
</configuration> </execution> </executions> </plugin> -->
</plugins>
</build>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>com.real</groupId>
<artifactId>AofCommon</artifactId>
<version>1.7.7</version>
</dependency>
<!-- validation -->
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-validator-annotation-processor</artifactId>
<version>5.3.4.Final</version>
</dependency>
<dependency>
<groupId>com.opencsv</groupId>
<artifactId>opencsv</artifactId>
<version>3.8</version>
</dependency>
<dependency>
<groupId>org.easytesting</groupId>
<artifactId>fest-assert</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>org.apache.httpcomponents</groupId>
<artifactId>httpclient</artifactId>
<version>4.5.2</version>
</dependency>
<!-- mockserver -->
<dependency>
<groupId>org.mock-server</groupId>
<artifactId>mockserver-netty</artifactId>
<version>3.10.4</version>
<exclusions>
<exclusion>
<groupId>xerces</groupId>
<artifactId>xercesImpl</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- SFTP library -->
<dependency>
<groupId>com.hierynomus</groupId>
<artifactId>sshj</artifactId>
<version>0.19.0</version>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>2.4</version>
</dependency>
<dependency>
<groupId>commons-codec</groupId>
<artifactId>commons-codec</artifactId>
<version>1.10</version>
</dependency>
<dependency>
<groupId>org.jboss.spec</groupId>
<artifactId>jboss-javaee-7.0</artifactId>
<type>pom</type>
<version>1.0.3.Final</version>
<scope>${default.scope}</scope>
</dependency>
<dependency>
<groupId>com.thoughtworks.xstream</groupId>
<artifactId>xstream</artifactId>
<version>1.4.9</version>
</dependency>
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-client</artifactId>
<version>3.0.11.Final</version>
<scope>${default.scope}</scope>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>4.3.10.Final</version>
<scope>${default.scope}</scope>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.8.5</version>
<scope>${default.scope}</scope>
</dependency>
<!-- LOGS -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.21</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.21</version>
</dependency>
<!-- TEST SCOPE -->
<dependency>
<groupId>org.glassfish</groupId>
<artifactId>javax.json</artifactId>
<version>1.0.4</version>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>org.mockito</groupId>
<artifactId>mockito-all</artifactId>
<version>1.10.19</version>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.12</version>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>org.testng</groupId>
<artifactId>testng</artifactId>
<version>6.10</version>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.testng</groupId>
<artifactId>arquillian-testng-container</artifactId>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>org.jboss.arquillian.protocol</groupId>
<artifactId>arquillian-protocol-servlet</artifactId>
<scope>${test.scope}</scope>
</dependency>
<dependency>
<groupId>org.jboss.shrinkwrap.resolver</groupId>
<artifactId>shrinkwrap-resolver-depchain</artifactId>
<scope>${test.scope}</scope>
<type>pom</type>
<exclusions>
<!-- eclipse sisu not working with WildFly so exclude it -->
<exclusion>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.inject</artifactId>
</exclusion>
<exclusion>
<groupId>org.eclipse.sisu</groupId>
<artifactId>org.eclipse.sisu.plexus</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.eu.ingwar.tools</groupId>
<artifactId>arquillian-suite-extension</artifactId>
<version>1.1.2</version>
<scope>${test.scope}</scope>
</dependency>
<!-- jacoco -->
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<version>1.0.0.Alpha9</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<version>0.7.8</version>
<scope>test</scope>
</dependency>
</dependencies>
<profiles>
<profile>
<id>test-coverage</id>
<build>
<plugins>
<plugin>
<groupId>org.jacoco</groupId>
<artifactId>jacoco-maven-plugin</artifactId>
<version>0.7.8</version>
<executions>
<execution>
<goals>
<goal>prepare-agent</goal>
</goals>
</execution>
<execution>
<id>default-prepare-agent-integration</id>
<goals>
<goal>prepare-agent-integration</goal>
</goals>
<configuration>
<destFile>${project.build.directory}/jacoco-it.exec</destFile>
</configuration>
</execution>
<execution>
<id>jacoco-site</id>
<phase>verify</phase>
<goals>
<goal>report</goal>
<goal>report-integration</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
<profile>
<id>integration-tests-wildfly</id>
<build>
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<failIfNoTests>false</failIfNoTests>
<excludedGroups>org.jboss.arquillian.testng.Arquillian</excludedGroups>
</configuration>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-failsafe-plugin</artifactId>
<version>2.19.1</version>
<configuration>
<systemPropertyVariables>
<jboss.server.log.dir>${jboss.home.dir}/standalone/log</jboss.server.log.dir>
<arquillian.launch>jbossas-managed</arquillian.launch>
<jbossas.startup.timeout>240</jbossas.startup.timeout>
</systemPropertyVariables>
<includes>
<include>**/*IT.java</include>
</includes>
</configuration>
<executions>
<execution>
<goals>
<goal>integration-test</goal>
<goal>verify</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
end of file`
arquilian.xml: `<?xml version="1.0" encoding="UTF-8"?> <arquillian xmlns="http://jboss.org/schema/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://jboss.org/schema/arquillian http://jboss.org/schema/arquillian/arquillian_1_0.xsd">
<!-- Force the use of the Servlet 3.0 protocol with all containers, as it is the most mature -->
<defaultProtocol type="Servlet 3.0" />
<!-- Keep generated archive for inspection
-->
<engine>
<property name="deploymentExportPath">target/</property>
</engine>
<!-- Local JBoss/WildFly instance -->
<container qualifier="jbossas-managed" default="true">
<configuration>
<property name="jbossHome">${env.JBOSS_HOME}</property>
<property name="serverConfig">standalone-real-continuous-integration.xml</property>
<!-- true : server must be started by the user, false : arquillian will start it itself -->
<property name="allowConnectingToRunningServer">true</property>
<property name="startupTimeoutInSeconds">${startup.timeout:360}</property>
</configuration>
</container>
<!-- Remote JBoss/WildFly instance -->
<container qualifier="jbossas-remote" default="false">
<configuration>
<property name="managementAddress">remoteHost</property>
<property name="managementPort">9999</property>
<property name="startupTimeoutInSeconds">${startup.timeout:360}</property>
</configuration>
</container>
`
and ArquillianDeploymentHelper:
`@ArquillianSuiteDeployment public class ArquillianDeploymentHelper {
public static final String DEPLOYMENT_NAME = "RflowHR";
private static final Logger LOGGER = LoggerFactory.getLogger(ArquillianDeploymentHelper.class);
private static final String WEBAPP_SRC = "src/main/webapp";
private static final String TEST_RESOURCES_SRC = "src/test/resources";
private static final String POM_FILE = "pom.xml";
private static final String ARCHIVE_NAME = "arquillian-RflowHR.war";
@Deployment(name = DEPLOYMENT_NAME)
public static Archive<?> generateDefaultDeployment() {
// Generate the default WAR used by all *IT tests using @OperateOnDeployment("AofPortal") annotation
LOGGER.info("Generating " + ARCHIVE_NAME + " archive ...");
PomEquippedResolveStage pom = Maven.resolver().loadPomFromFile(POM_FILE);
ScopeType[] scopes = {ScopeType.COMPILE, ScopeType.IMPORT, ScopeType.TEST}; // no SYSTEM and no PROVIDED
File[] libs = pom.importDependencies(scopes).resolve().using(TransitiveStrategy.INSTANCE).asFile();
WebArchive archive = ShrinkWrap.create(WebArchive.class, ARCHIVE_NAME)
.addAsLibraries(libs)
.addAsResource("com/real/hr/services/impl/test/insertMinimalEmployee.xml")
//.addAsResource(new File(TEST_RESOURCES_SRC, "test-configuration.properties"), "configuration.properties")
.addPackages(true, "com.real")
//.addAsWebInfResource(new File(WEBAPP_SRC, "WEB-INF/web.xml"))
.addAsWebInfResource(new File(WEBAPP_SRC, "WEB-INF/beans.xml"))
.addAsWebInfResource(new File(WEBAPP_SRC, "WEB-INF/jboss-web.xml"))
.addAsWebInfResource(new File(TEST_RESOURCES_SRC, "persistence.xml"), "classes/META-INF/persistence.xml");
//.addAsManifestResource(new File(WEBAPP_SRC, "META-INF/jboss-deployment-structure.xml"));
// No need to log the content anymore, the archive is kept in target directory
// "deploymentExportPath" variable in arquillian.xml
// LOGGER.info(archive.toString(true));
LOGGER.info(archive.toString(true));
return archive;
}
}`
i run it with testNG but tried with junit same result... code coverage for test unit ok not for Integration tests, jacoco-it.exe is created
i manage to make it work by adding in arquillian.xml include packages, only my local project packages
`<extension qualifier="jacoco">
<property name="includes">com.your.package.*</property>
</extension>`
I have the same problem. My Jacoco version is 0.7.8 but tried 0.7.9 too. The extension is taken from Arquillian Universe 1.1.13.2 which has version of Jacoco Extension 1.0.0.Alpha9.
If you like me to make a prototype, I may push a new git repo in my account.
16:31:44,351 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-3) MSC000001: Failed to start service jboss.deployment.unit."ejb-async-audituser-1.0.war".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."ejb-async-audituser-1.0.war".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "ejb-async-audituser-1.0.war" at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154) at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) Caused by: java.lang.StackOverflowError at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.$jacocoInit(ArquillianRuntime.java) at org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java)
That would be awesome, so we could try to reproduce. So far I wasn't able to. Can you also give us a bit more context of your environment?
@bartoszmajsak
I use JDK 1.8.0_121, arquillian-chameleon
with wildfly:10.1.0.Final:managed
, javax:javaee-api:7.0
, port offset allocated via build-helper-maven-plugin
. Small project.
I have the same kind issue but with nu.validator instead of arquillian. Note that it's a little flickering (I get the StackOverflowError almost all the time but from time to time it's passing).
Here is a simple Maven project that reproduce the bug (might help identify in arquillian side): stackoverflow.zip
See https://github.com/jacoco/jacoco/issues/528 on jacoco side.
stackOverFlow error is because to much class are scanned with no needed fill the file arquillian.xml with include and exlude class, i manage to make it work with this config and downgrade version of testNG
thank you @leccyril for proposing the workaround. @Tibor17 @jurajcik does it fix the issue you are/were facing?
in my previous post i manage to make it work by adding in arquillian.xml include packages, only my local project packages
`
`
because in archive deployer to many lib are imported and then scanned... jacoco does'nt support it and moreover does'nt need to scan lib we want to scan our code...
@MatousJobanek I want to recover my old project with Arquillian and check it out. Let you know.
@MatousJobanek
Here is the project
https://github.com/Tibor17/arquillian-extension-jacoco
but now it works with Arquillian Chameleon
and no StackOverflowError
anymore.
I have no idea what has changed. I will try to find shelfs in my old project and maybe I will find out the cause.
May I have a question?
How can I share *.exec
across JVM processes and extend coverage. I use maven-invoker-plugin
which isolates ITs from main process of Maven.
I guess I should share the path to agent
used in argLine
in Surefire in main process and invoker plugin
as well.
@MatousJobanek I have now problem with use of AssetJ on Arquillian. Suddenly we have a problem with compatibility with ASM version.
JaCoCo is using asm-debug-all:5.2
but Arquillian is using asm:3.3.1
.
The problem is class or interface org.objectweb.asm.ClassVisitor
.
It is interface in 3.3.1 but abstract class in 5.2.
org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/lib/assertj-core-3.6.2.jar Caused by: org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/lib/assertj-core-3.6.2.jar Caused by: org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /WEB-INF/lib/assertj-core-3.6.2.jar Caused by: org.jboss.shrinkwrap.api.exporter.ArchiveExportException: Failed to write asset to output: /org/assertj/core/api/AbstractArrayAssert.class Caused by: java.lang.IncompatibleClassChangeError: class org.jacoco.core.internal.flow.ClassProbesVisitor has interface org.objectweb.asm.ClassVisitor as super class
Asm is most likely coming as transitive dependency, can you check how maven is resolving that so we can see why we are having this mess on the classpath?
I checked very big number of source from which ASM is coming. The dependency tree was very big, IDEA run OOM on it.
Does arquillian-assertj.jar
exist similar to arquillian-junit.jar
?
Why AssertJ triggered this issue?
What about maven dependency:tree
?
There is no such thing as arquillian-assertj
i had this problem with apache tika, it had old version of ASM, just make exclusion of aSM in the lib cause issue, in eclipse you can see dependancy hierarchie to see what lib is omitted and replace by what lib... i spet several days on this issue
The ASM problem goes with WildFly and then Arquillian. So I reported an issue in WildFly in order to upgrade ASM and CXF. https://issues.jboss.org/browse/WFLY-9406 Reported in GitHub https://github.com/wildfly/wildfly/issues/10531
For those still limited to an old server (like JBoss EAP 6.4): I have created #72 and I'll try to come up with a PR.
Can someone try the new arquillian-jacoco-with-asm
flavour (version 1.1.0
)?
This should fix such StackOverflowErrors
but beware that jacoco
version is pinned to 0.8.5 with that approach.
I just enabled JaCoCo coverage for our integ tests using this plugin in a Gradle build and am facing a SOE too. I don't think it is because of a too old server, it is basically a WildFly 18.0.1. Neither too old Java, which is OpenJDK 11.0.5. This is a big multi-project build and it has 20 integ test tasks that use arquillian. All work in the same principle, our whole final ear is enriched with the test classes and then deployed and tests executed. We do not build a stripped down ear with only the relevant classes to not have to manually specify what might be necessary and closer resemble production state during integ test.
For 19 of the tasks the deployment and testing works perfectly fine. But for one of them the deployment reproducably fails with this:
-:<23.04.2020 12:49:55,379><ERROR><org.jboss.msc.service.fail><MSC service thread 1-2><><><><MSC000001: Failed to start service jboss.deployment.unit."mod-rpbo-integTest-2020R1.ear".POST_MODULE: org.jboss.msc.service.StartException in service jboss.deployment.unit."mod-rpbo-integTest-2020R1.ear".POST_MODULE: WFLYSRV0153: Failed to process phase POST_MODULE of deployment "mod-rpbo-integTest-2020R1.ear"
at org.jboss.as.server@10.0.3.Final//org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:183)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1739)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$StartTask.execute(ServiceControllerImpl.java:1701)
at org.jboss.msc@1.4.11.Final//org.jboss.msc.service.ServiceControllerImpl$ControllerTask.run(ServiceControllerImpl.java:1559)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads@2.3.3.Final//org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1363)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: java.lang.StackOverflowError
at deployment.mod-rpbo-integTest-2020R1.ear//org.jacoco.core.runtime.RuntimeData.$jacocoInit(RuntimeData.java)
at deployment.mod-rpbo-integTest-2020R1.ear//org.jacoco.core.runtime.RuntimeData.<init>(RuntimeData.java)
at deployment.mod-rpbo-integTest-2020R1.ear//org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.<init>(ArquillianRuntime.java:49)
at deployment.mod-rpbo-integTest-2020R1.ear//org.jboss.arquillian.extension.jacoco.container.ArquillianRuntime.getInstance(ArquillianRuntime.java:38)
and then another 255 times the last 4 lines
Hm, it seems for us here it is because someone managed to many libs to the integTest ear that should not be there, including all kinds of arquillian, shrinkwrap, wildfly JARs.
I have the configuration with jacoco-maven-plugin and arquillian-jacoco as described in the README, while using a managed jboss-eap-6.4. Without the jacoco plugin, the tests run fine, but the jacoco plugin causes the StackOverflowError.
... the last two lines repeat for ever. Please, any idea what is wrong?