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.
Related
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
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
Running instrumentation tests with RESTMock we are getting this error
java.lang.NoSuchMethodError: No static method copyInto$default([Ljava/lang/Object;[Ljava/lang/Object;IIIILjava/lang/Object;)[Ljava/lang/Object; in class Lkotlin/collections/ArraysKt; or its super classes (declaration of 'kotlin.collections.ArraysKt' appears in /data/app/com.example.debug-1/base.apk)
FATAL EXCEPTION: pool-6-thread-1
Process: com.example.debug, PID: 6606
java.lang.NoSuchMethodError: No static method copyInto$default([Ljava/lang/Object;[Ljava/lang/Object;IIIILjava/lang/Object;)[Ljava/lang/Object; in class Lkotlin/collections/ArraysKt; or its super classes (declaration of 'kotlin.collections.ArraysKt' appears in /data/app/com.example.debug-1/base.apk)
at okhttp3.tls.internal.TlsUtil.newKeyManager(TlsUtil.kt:84)
at okhttp3.tls.HandshakeCertificates$Builder.build(HandshakeCertificates.kt:144)
at io.appflate.restmock.SslUtils.localhost(SslUtils.java:49)
at io.appflate.restmock.RESTMockServer.setUpHttps(RESTMockServer.java:91)
at io.appflate.restmock.RESTMockServer.init(RESTMockServer.java:74)
at io.appflate.restmock.RESTMockServerStarter$1.run(RESTMockServerStarter.java:56)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1133)
This is the line in question in OkHttp
IIUC, Kotlin can treat a varargs as a Kotlin Array and then call extensions functions like copyInto
We're on OkHttp 4.0.1, Kotlin 1.3.40, R8 1.5.41
Our test apk correctly contains copyInto method so I don't think it's a proguard/R8 issue:
I'm at a loss as to what to test next. I asked on OkHttp's github issuse page and they suggested I post here link
Update: still happening on OkHttp 4.1.0. Also I realized that it can't be an R8 issue since R8 doesn't remove code from test apk.
I had a same issue , then added the mentioning lib to my project. It solved my problem:
maven :
<!-- https://mvnrepository.com/artifact/org.jetbrains.kotlin/kotlin-stdlib -->
<dependency>
<groupId>org.jetbrains.kotlin</groupId>
<artifactId>kotlin-stdlib</artifactId>
<version>1.3.70</version>
</dependency>
or
'org.jetbrains.kotlin:kotlin-stdlib:1.3.70'
I got the same issue when I was using okhttp3.mockwebserver.MockWebServer with https enabled with a server certificate from okhttp-tls.
In my case, the problem was that by just importing the com.squareup.okhttp3:okhttp-tls:4.2.0 dependency, org.jetbrains.kotlin:kotlin-stdlib was being resolved to version 1.2.71.
Given the copyInto method was introduced starting kotlin 1.3 it was failing with the same error you have.
I fixed it by adding explicitly the kotlin version in my gradle.build file:
testRuntime 'org.jetbrains.kotlin:kotlin-stdlib:1.3.50'
I got the same issue, but I'm developing a multi-module java project. It was useful that add a dependency for kotlin-stdlib in pom.xml that belongs to this module while unit testing...
When I boot this whole project, this issue came out agnain. Finally, I find this dependency need to be in the whole project's pom.xml, I mean the pom.xml in the project's root dir.
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.
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.