Maven test fails within install phase but is ok within test phase - testing

I have an empty java test with Spring and Ebean
protected static ApplicationContext ctx;
#BeforeClass
public static void initSpringContext() {
ctx = new ClassPathXmlApplicationContext("spring-context.xml");
}
public class SomeTest extends SpringBase {
#Test
public void emptyTest() {}
}
I had a problem with class loading:
Caused by: javax.persistence.PersistenceException: models.Flat is NOT an Entity Bean registered with this server?
Problem was fixed with pom config
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-surefire-plugin</artifactId>
<version>2.12.4</version>
<configuration>
<useSystemClassLoader>false</useSystemClassLoader>
</configuration>
</plugin>
After this fix "mvn clean test" runs ok, but "mvn clean install" fails with exact exception
I suppose it's because integration-test phase.
I tried to config useSystemClassLoader in maven-failsafe-plugin, run with param -Dskip.integration.test=true but is makes no difference, I have feeling that this plugin did not call at all.
Also I've compared surefire-reports genereted by "mvn clean test" and "mvn clean verify" -- section "properties" within the testsuite is identical in both cases.
Skipping integration-test will be also an acceptable solution.
Maven 2.2.1 OS - Tested under Windows and Debian
If it can help, stacktrace of error:
Caused by: javax.persistence.PersistenceException: models.Flat is NOT an Entity Bean registered with this server?
at com.avaje.ebeaninternal.server.core.DefaultServer.createQuery(DefaultServer.java:1008)
at com.avaje.ebeaninternal.server.core.DefaultServer.createQuery(DefaultServer.java:965)
at com.avaje.ebeaninternal.server.core.DefaultServer.find(DefaultServer.java:1001)
at com.avaje.ebean.Ebean.find(Ebean.java:1143)
at flats.crawler.managers.CrawlerManager.initCrawlerHashes(CrawlerManager.java:25)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleElement.invoke(InitDestroyAnnotationBeanPostProcessor.java:346)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor$LifecycleMetadata.invokeInitMethods(InitDestroyAnnotationBeanPostProcessor.java:299)
at org.springframework.beans.factory.annotation.InitDestroyAnnotationBeanPostProcessor.postProcessBeforeInitialization(InitDestroyAnnotationBeanPostProcessor.java:132)
... 48 more
I've run two commands "mvn clean install -X" and "mvn clean test -X" and compared test classpathes:
in first case
[DEBUG] PATH\MODULE\target\MODULE-1.0.jar
in second case
[DEBUG] PATH\MODULE\target\classes
that's why Ebean can't find classes

For integration tests the maven-failsafe-plugin is responsible and NOT the maven-surefire plugin. So you configurations to ignore the integration test couldn't work.

Did you see this FAQ entry in the failsafe plugin docs? It gives a whole bunch of options for classloading configuration.
If none of those suggestions work for you, and skipping the integration tests is okay (as you mentioned), then -DskipITs=true should do it, per the docs.

Related

Gatling with Karate (Maven project): I'm trying to setup Gatling in my existing karate project but during build it is failing as follows [duplicate]

When I try to run a Gatling performance test with Karate, I get the following in the error log.
Simulation perf.SVTKarateSimulation started...
17:55:28.277 [GatlingSystem-akka.actor.default-dispatcher-2][ERROR][Action.scala:71] c.i.k.g.KarateAction - 'classpath:com/TCEU/KarateTests/Test.feature' crashed with 'j.l.NullPointerException', forwarding to the next one
This is how my pom file looks:
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>3.0.4</version>
<configuration>
<simulationsFolder>src/test/java</simulationsFolder>
<includes>
<include>perf.SVTKarateSimulation</include>
</includes>
<jvmArgs>
<jvmArg>-Dfile.encoding=UTF-8</jvmArg>
</jvmArgs>
</configuration>
</plugin>
And using Karate-Gatling 0.9.5.RC4
This is how my scala file:
package perf
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration._
import io.gatling.http.Predef._
class SVTKarateSimulation extends Simulation {
val create = scenario("Get api").exec(karateFeature("classpath:com/TCEU/KarateTests/test.feature"))
setUp(
create.inject(rampUsers(10) during (10 seconds)))
}
And the test.feature file:
Feature: Gatling test
Background:
* url 'https://regres.in'
Scenario: Get api
Given path '/api/users/2'
When method GET
Then status 200
I looked at solutions provided in
Crashed with 'j.l.NullPointerException' when i try to run karate-gatling test reports
and also
https://github.com/intuit/karate/issues/404
But the solutions provided in that does not help either.
I am using Windows 10 with Eclipse Version: 2019-09 R (4.13.0).
I tried to run another project related feature file but that gave the same error so tried a simple test following a video tutorial - https://www.youtube.com/watch?v=RrRhndl-osY
Can someone kindly help please?
For the benefit of anyone else who faces this issue, the solution is to keep your pom.xml consistent with same version of Karate. My karate-gatling was 0.9.5.RC4 where as karate-apache was 0.9.4. When I made them both 0.9.5.RC4, I did not face these issues. Make sure pom.xml is consistent.
And if anyone runs into this kind of issue when compiling / running:
15:22:28.250 [main] ERROR io.gatling.compiler.ZincCompiler$ - one error found
15:22:28.252 [main] ERROR io.gatling.compiler.ZincCompiler$ - Compilation crashed
sbt.internal.inc.CompileFailed: null
at sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:242)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:111)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:90)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:82)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:133)
at sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:73)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:116)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.Incremental$.doCompile(Incremental.scala:106)
at sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:87)
at sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:63)
at sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:89)
at sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:134)
at sbt.internal.inc.Incremental$.compile(Incremental.scala:80)
at sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:67)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:311)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:269)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:159)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:238)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:69)
at io.gatling.compiler.ZincCompiler$.doCompile(ZincCompiler.scala:210)
at io.gatling.compiler.ZincCompiler$.delayedEndpoint$io$gatling$compiler$ZincCompiler$1(ZincCompiler.scala:215)
at io.gatling.compiler.ZincCompiler$delayedInit$body.apply(ZincCompiler.scala:39)
at scala.Function0.apply$mcV$sp(Function0.scala:39)
at scala.Function0.apply$mcV$sp$(Function0.scala:39)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:17)
at scala.App.$anonfun$main$1$adapted(App.scala:80)
at scala.collection.immutable.List.foreach(List.scala:392)
at scala.App.main(App.scala:80)
at scala.App.main$(App.scala:78)
at io.gatling.compiler.ZincCompiler$.main(ZincCompiler.scala:39)
at io.gatling.compiler.ZincCompiler.main(ZincCompiler.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.gatling.mojo.MainWithArgsInFile.runMain(MainWithArgsInFile.java:50)
at io.gatling.mojo.MainWithArgsInFile.main(MainWithArgsInFile.java:33)
This is likely to be because on Windows, the Java bin folder is not added to the System PATH. See the below thread for more details.
https://github.com/intuit/karate/issues/404#issuecomment-417630286

GatlingSystem-akka.actor.default-dispatcher-2 error - crashed with 'j.l.NullPointerException' when running Karate Gatling test

When I try to run a Gatling performance test with Karate, I get the following in the error log.
Simulation perf.SVTKarateSimulation started...
17:55:28.277 [GatlingSystem-akka.actor.default-dispatcher-2][ERROR][Action.scala:71] c.i.k.g.KarateAction - 'classpath:com/TCEU/KarateTests/Test.feature' crashed with 'j.l.NullPointerException', forwarding to the next one
This is how my pom file looks:
<plugin>
<groupId>io.gatling</groupId>
<artifactId>gatling-maven-plugin</artifactId>
<version>3.0.4</version>
<configuration>
<simulationsFolder>src/test/java</simulationsFolder>
<includes>
<include>perf.SVTKarateSimulation</include>
</includes>
<jvmArgs>
<jvmArg>-Dfile.encoding=UTF-8</jvmArg>
</jvmArgs>
</configuration>
</plugin>
And using Karate-Gatling 0.9.5.RC4
This is how my scala file:
package perf
import com.intuit.karate.gatling.PreDef._
import io.gatling.core.Predef._
import scala.concurrent.duration._
import io.gatling.http.Predef._
class SVTKarateSimulation extends Simulation {
val create = scenario("Get api").exec(karateFeature("classpath:com/TCEU/KarateTests/test.feature"))
setUp(
create.inject(rampUsers(10) during (10 seconds)))
}
And the test.feature file:
Feature: Gatling test
Background:
* url 'https://regres.in'
Scenario: Get api
Given path '/api/users/2'
When method GET
Then status 200
I looked at solutions provided in
Crashed with 'j.l.NullPointerException' when i try to run karate-gatling test reports
and also
https://github.com/intuit/karate/issues/404
But the solutions provided in that does not help either.
I am using Windows 10 with Eclipse Version: 2019-09 R (4.13.0).
I tried to run another project related feature file but that gave the same error so tried a simple test following a video tutorial - https://www.youtube.com/watch?v=RrRhndl-osY
Can someone kindly help please?
For the benefit of anyone else who faces this issue, the solution is to keep your pom.xml consistent with same version of Karate. My karate-gatling was 0.9.5.RC4 where as karate-apache was 0.9.4. When I made them both 0.9.5.RC4, I did not face these issues. Make sure pom.xml is consistent.
And if anyone runs into this kind of issue when compiling / running:
15:22:28.250 [main] ERROR io.gatling.compiler.ZincCompiler$ - one error found
15:22:28.252 [main] ERROR io.gatling.compiler.ZincCompiler$ - Compilation crashed
sbt.internal.inc.CompileFailed: null
at sbt.internal.inc.AnalyzingCompiler.call(AnalyzingCompiler.scala:242)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:111)
at sbt.internal.inc.AnalyzingCompiler.compile(AnalyzingCompiler.scala:90)
at sbt.internal.inc.MixedAnalyzingCompiler.$anonfun$compile$3(MixedAnalyzingCompiler.scala:82)
at scala.runtime.java8.JFunction0$mcV$sp.apply(JFunction0$mcV$sp.java:23)
at sbt.internal.inc.MixedAnalyzingCompiler.timed(MixedAnalyzingCompiler.scala:133)
at sbt.internal.inc.MixedAnalyzingCompiler.compileScala$1(MixedAnalyzingCompiler.scala:73)
at sbt.internal.inc.MixedAnalyzingCompiler.compile(MixedAnalyzingCompiler.scala:116)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileInternal$1$adapted(IncrementalCompilerImpl.scala:307)
at sbt.internal.inc.Incremental$.doCompile(Incremental.scala:106)
at sbt.internal.inc.Incremental$.$anonfun$compile$4(Incremental.scala:87)
at sbt.internal.inc.IncrementalCommon.recompileClasses(IncrementalCommon.scala:116)
at sbt.internal.inc.IncrementalCommon.cycle(IncrementalCommon.scala:63)
at sbt.internal.inc.Incremental$.$anonfun$compile$3(Incremental.scala:89)
at sbt.internal.inc.Incremental$.manageClassfiles(Incremental.scala:134)
at sbt.internal.inc.Incremental$.compile(Incremental.scala:80)
at sbt.internal.inc.IncrementalCompile$.apply(Compile.scala:67)
at sbt.internal.inc.IncrementalCompilerImpl.compileInternal(IncrementalCompilerImpl.scala:311)
at sbt.internal.inc.IncrementalCompilerImpl.$anonfun$compileIncrementally$1(IncrementalCompilerImpl.scala:269)
at sbt.internal.inc.IncrementalCompilerImpl.handleCompilationError(IncrementalCompilerImpl.scala:159)
at sbt.internal.inc.IncrementalCompilerImpl.compileIncrementally(IncrementalCompilerImpl.scala:238)
at sbt.internal.inc.IncrementalCompilerImpl.compile(IncrementalCompilerImpl.scala:69)
at io.gatling.compiler.ZincCompiler$.doCompile(ZincCompiler.scala:210)
at io.gatling.compiler.ZincCompiler$.delayedEndpoint$io$gatling$compiler$ZincCompiler$1(ZincCompiler.scala:215)
at io.gatling.compiler.ZincCompiler$delayedInit$body.apply(ZincCompiler.scala:39)
at scala.Function0.apply$mcV$sp(Function0.scala:39)
at scala.Function0.apply$mcV$sp$(Function0.scala:39)
at scala.runtime.AbstractFunction0.apply$mcV$sp(AbstractFunction0.scala:17)
at scala.App.$anonfun$main$1$adapted(App.scala:80)
at scala.collection.immutable.List.foreach(List.scala:392)
at scala.App.main(App.scala:80)
at scala.App.main$(App.scala:78)
at io.gatling.compiler.ZincCompiler$.main(ZincCompiler.scala:39)
at io.gatling.compiler.ZincCompiler.main(ZincCompiler.scala)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at io.gatling.mojo.MainWithArgsInFile.runMain(MainWithArgsInFile.java:50)
at io.gatling.mojo.MainWithArgsInFile.main(MainWithArgsInFile.java:33)
This is likely to be because on Windows, the Java bin folder is not added to the System PATH. See the below thread for more details.
https://github.com/intuit/karate/issues/404#issuecomment-417630286

Test fails due to objectproperties file can't be found

I've mobile automation test cases written in Selenium, Appium & TestNG.
Invoking test cases works fine when run from eclipse, but when I run the batch script by invoking testng.xml test fails as it's failing to find object property file.
And fails with following error stack
java.lang.NoSuchMethodError: com.google.common.collect.ImmutableSet.toImmutableSet()Ljava/util/stream/Collector;
at org.openqa.selenium.remote.ProtocolHandshake.streamW3CProtocolParameters(ProtocolHandshake.java:284)
at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:149)
at org.openqa.selenium.remote.HttpCommandExecutor.execute(HttpCommandExecutor.java:142)
at org.openqa.selenium.remote.RemoteWebDriver.execute(RemoteWebDriver.java:637)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:250)
at org.openqa.selenium.remote.RemoteWebDriver.startSession(RemoteWebDriver.java:236)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:137)
at org.openqa.selenium.remote.RemoteWebDriver.<init>(RemoteWebDriver.java:174)
at com.xyz.xya.LeadTest.Launchapplication(RetailKeywords.java:47)
at com.xyz.xya.LeadTest.readData(RetailExecuteLead.java:111)
Suppressed: java.io.IOException: Incomplete document
at com.google.gson.stream.JsonWriter.close(JsonWriter.java:527)
at org.openqa.selenium.remote.ProtocolHandshake.createSession(ProtocolHandshake.java:167)
... 35 more
... Removed 27 stack
Use Maven Surefire Plugin if you are relying on running your tests from terminal mode or batch mode. And also, make sure you mention your test resources inside the build tag of your pom.xml like so.
<build>
<testResources>
<testResource>
<directory>src/test/resources</directory>
<filtering>false</filtering>
</testResource>
</testResources>
</build>
Now whenever you have to load your property file do so using an InputStream of some sorts. Or simply using the File class.
InputStream is = getClass().getResourceAsStream("/object.properties");
What the above stuff does is, during the build, maven knows where to pick the resource file from. And since you have mentioned the resources in pom, you can directly get the file using classpath without using file-systems directly.
#SteroidKing666 thanks a lot for the guidance.
As suspected by you it was due to conflict of multiple versions of Guava I had 17.0 & 21.0
I removed 17.0 and kept 21.0 version of it and then vooila it works.

Cargo - Jetty9 - Unexpected error when trying to start the webapp

I'm stuck on deploying a war to a remote Jetty 9.
On the app-server side I've deployed the cargo-jetty-7-and-onwards-deployer (version 1.4.9). This component seems to be running correctly and responds with (as expected on a get request):
HTTP ERROR 400
Problem accessing /cargo-jetty-deployer/. Reason:
Command / is unknown Powered by Jetty://
To deploy I'm using the cargo-maven2-plugin (version 1.4.9) with this configuration:
<plugin>
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>${cargo.plugin.version}</version>
<configuration>
<container>
<containerId>jetty9x</containerId>
<type>remote</type>
</container>
<configuration>
<type>runtime</type>
<properties>
<cargo.servlet.port>80</cargo.servlet.port>
<cargo.hostname>ipgoeshere</cargo.hostname>
<cargo.protocol>http</cargo.protocol>
</properties>
</configuration>
<deployables>
<deployable>
<groupId>se.dn.nav</groupId>
<artifactId>nav-api</artifactId>
<type>war</type>
<properties>
<context>/api</context>
</properties>
</deployable>
</deployables>
</configuration>
</plugin>
When running: mvn cargo:deploy
this results in the following error message:
[ERROR] Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy (default-cli) on project nav-api: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:108)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:76)
at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:116)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:361)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:584)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:213)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:157)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default-cli of goal org.codehaus.cargo:cargo-maven2-plugin:1.4.9:deploy failed: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:144)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
... 19 more
Caused by: org.codehaus.cargo.container.ContainerException: Failed to deploy [/var/lib/jenkins/jobs/Deploy-Stage/workspace/target/nav-api-1.2.war]
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:126)
at org.codehaus.cargo.maven2.DeployerDeployMojo.performDeployerActionOnSingleDeployable(DeployerDeployMojo.java:56)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.performDeployerActionOnAllDeployables(AbstractDeployerMojo.java:166)
at org.codehaus.cargo.maven2.AbstractDeployerMojo.doExecute(AbstractDeployerMojo.java:97)
at org.codehaus.cargo.maven2.AbstractCargoMojo.execute(AbstractCargoMojo.java:432)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:133)
... 20 more
Caused by: org.codehaus.cargo.container.ContainerException: Response when calling http://ip:80/cargo-jetty-deployer/deploy?path=/api was: Error - Unexpected error when trying to start the webapp
at org.codehaus.cargo.container.jetty.JettyRemoteDeployer.deploy(JettyRemoteDeployer.java:119)
... 25 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginExecutionException
And after this the build and deployment fails.
I've checked the logs on the Jetty, I've also upped the logging level to DEBUG, but there's no indication what is going wrong on the server side.
Does anyone have a clue what I'm doing wrong?
Is there any way I can get a better error message to indicate whats going wrong?
Any help would be GREATLY appreciated! :)
P.s.
I've removed the ip int the log.
P.s.s.
The war I'm deploying is previously tested and runs fine on Jetty.
Seems like cargo-jetty-7-and-onwards-deployer is not compatible with Jetty 9+ (there were some lifecycle changes in Jetty 9 that cargo is likely not aware of)
Do this (to find out) ...
Start jetty with the following extra command line
java -jar /opt/jetty/start.jar -Dorg.LEVEL=DEBUG -Djetty.dump.start=true
Check the logs, there should be tons more information, including a server state dump.
If cargo-jetty-deployer is either not present or not labeled as STARTED then the deployer webapp itself failed to start.
If you feel like it, update your question with the dump and/or relevant webapp startup error logging events (not the entire log, as that is just far to noisy)
What worked for me is setting the config.home system property to the parent directory of the webapps directory of Jetty.
The deployer will copy the uploaded war to the webapps directory and let Jetty deploy it automatically.
If config.home is set then the deployer will use ${config.home}/webapps, if not then it will use ${jetty.home}/webapps as the target directory for the war file. For me the webapps directory is configured to be ${jetty.base}/webapps which is something different than ${jetty.home}/webapps. Setting ${config.home} equal to ${jetty.base} solved the issue.

How do I get Hudson to generate a Findbugs report without failing due to an exception?

Update
As of Hudson Findbugs plug-in version 4.3 this is no longer an issue
End Update
As an example of my problem, I'm trying to build the following project http://www.sonatype.com/books/mvnex-book/reference/multimodule.html
I added the following to simple-parent/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
<version>2.3</version>
<configuration>
<findbugsXmlOutput>true</findbugsXmlOutput>
<findbugsXmlWithMessages>true</findbugsXmlWithMessages>
<xmlOutput>true</xmlOutput>
</configuration>
</plugin>
</plugins>
</reporting>
And the following to simple-weather/pom.xml and simple-webapp/pom.xml
<reporting>
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>findbugs-maven-plugin</artifactId>
</plugin>
</plugins>
</reporting>
I inserted the following horrible equals method into one of the classes to have FindBugs generate some issues (as there is no error on 0 bugs):
public boolean equals(Object o) { return true; }
I'm using Hudson with a maven2 style project. The job is aimed at the simple-parent pom with the goals
clean site
I get the following exception:
[INFO] Generating "FindBugs Report" report.
[java] Warnings generated: 2
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Cannot inherit from final class
[INFO] ------------------------------------------------------------------------
[INFO] Trace
java.lang.VerifyError: Cannot inherit from final class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
at java.net.URLClassLoader.defineClass(URLClassLoader.java:260)
at java.net.URLClassLoader.access$100(URLClassLoader.java:56)
at java.net.URLClassLoader$1.run(URLClassLoader.java:195)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at hudson.remoting.RemoteClassLoader$ClassLoaderProxy.fetch2(RemoteClassLoader.java:370)
at sun.reflect.GeneratedMethodAccessor594.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at hudson.remoting.RemoteInvocationHandler$RPCRequest.perform(RemoteInvocationHandler.java:274)
at hudson.remoting.Request$2.run(Request.java:270)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:417)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:269)
at java.util.concurrent.FutureTask.run(FutureTask.java:123)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:651)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:676)
at java.lang.Thread.run(Thread.java:595)
Version info:
Maven 2.2.1
Java 1.5.0_22
Hudson 1.341 (also found on 1.339) running inside JBoss 4.0.5.GA (same error on 4.2.2.GA and 5.1.0.GA)
Maven FindBugs plugin 2.3
Hudson FindBugs plugin 4.1
Any ideas on how to fix this?
According to the FindBugs FAQ, this problem occurs when the wrong version of Apache BCEL is being used (see Q2: When I click the "Find Bugs!" button, I get a NoSuchMethodError or VerifyError). In your case, I suspect that the maven-findbugs-plugin is getting the BCEL library from JBoss because of some obscure classloading issue. There are some very similar bugs in Hudson's Jira, e.g. HUDSON-5134 (the hudson findbugs plugin is also affected).
My understanding is that this problem has been introduced recently (in v1.338) and, even if there is a workaround, it is an Hudson bug (it is a regression, it's not a problem with JBoss).
Now, you have IMO two solutions:
Use a version of Hudson anterior to v1.338 (the regression was reported for this version) but using an old version and sticking with it is certainly not really a viable solution.
Remove or replace the bcel.jar of JBoss (in server/SERVERNAME/lib) with the version used by the maven-findbugs-plugin (see dependencies). I'm not able to say how this will affect JBoss exactly (If you remove it, it seems that you will loose the ability to run JBoss in debug-mode but I can't say if everything will work fine if you replace it).
Whatever you'll do, please create a new Jira issue (http://issues.hudson-ci.org/) as this is a regression in Hudson. They have marked HUDSON-5134 as "Won't fix" because there is a workaround but I don't think that messing with JBoss libraries is a good solution (I'm repeating myself but this is a Hudson bug). So, insisting and letting Hudson developers know that other users are affected by this problem will help all the entire community (at least, I hope so).
The other answers provided are better, but one alternative to add: use Ant or batch file to create a separate build step that doesn't care that the FindBugs step failed. The Hudson plug-in can still be used to display the results.
As Pascal points out, there is a similar bug filed - HUDSON-5134 - and that bug indicates the behavior started with Hudson release 1.338. Since Hudson releases once a week, it can be difficult to pin down which version introduced a bug. I notice there was a classloader related change released with Hudson version 1.337 (HUDSON-5048), and I suspect that is causing the problem here, but I don't have direct evidence of that.
But that likely means you need to roll back to 1.337 or earlier to avoid this problem.