I am trying to run my integration tests via a Jenkins build using Maven running JUnit and Arquillian. When I run on my local Windows machine, everything runs fine (without Jenkins). But when I try to build using Jenkins on Linux, I am getting the following error:

com.ibm.myw3.services.taskcalendar.ejb.test.TaskCalendarManagerIT
com.ibm.myw3.services.taskcalendar.ejb.test.TaskCalendarManagerIT  Time elapsed: 0.446 sec  <<< ERROR!
java.lang.RuntimeException: Could not create new instance of class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor
     at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:160)
...
Caused by: java.lang.reflect.InvocationTargetException: null
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:86)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:58)
at java.lang.reflect.Constructor.newInstance(Constructor.java:542)
at org.jboss.arquillian.test.spi.SecurityActions.newInstance(SecurityActions.java:156)
...
Caused by: java.lang.NoClassDefFoundError: com.sun.tools.attach.VirtualMachine
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:986)
at org.jboss.arquillian.core.impl.Reflections.getObserverMethods(Reflections.java:52)
at org.jboss.arquillian.core.impl.ExtensionImpl.of(ExtensionImpl.java:55)
at org.jboss.arquillian.core.impl.ManagerImpl.inject(ManagerImpl.java:211)
at org.jboss.arquillian.core.impl.InjectorImpl.inject(InjectorImpl.java:58)
at org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader.createServiceInstance(ServiceRegistryLoader.java:108)
at org.jboss.arquillian.core.impl.loadable.ServiceRegistryLoader.all(ServiceRegistryLoader.java:55)
...

Caused by: java.lang.ClassNotFoundException: com.sun.tools.attach.VirtualMachine
at java.net.URLClassLoader.findClass(URLClassLoader.java:600)
at java.lang.ClassLoader.loadClassHelper(ClassLoader.java:941)
at java.lang.ClassLoader.loadClass(ClassLoader.java:868)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:326)
at java.lang.ClassLoader.loadClass(ClassLoader.java:846)
at java.lang.Class.getDeclaredMethodsImpl(Native Method)
at java.lang.Class.getDeclaredMethods(Class.java:986)
at org.jboss.arquillian.core.impl.Reflections.getObserverMethods(Reflections.java:52)

None of my other colleagues are getting this error when running in the same environment, so I'm not sure if my Arquillian tests are using some other functionality that no one else is.

That "missing" 'tools.jar' file is in the JDK that I am using (and yes, I have verified that the correct JDK is being used). I've even tried to add the jar to the CLASSPATH of the running Maven step, but nothing resolves the error.

Does this look familiar to anyone? Does that 'VirtualMachine' class only get called under certain circumstances? Does anyone know what those circumstances are? I'm going under the assumption that my code is the only one that is causing that class to be loaded, and none of my colleagues are - but that might be a bad assumption.

Hi Dave,

the attach API is always used by the wlp-managed-8.5 container implementation; it is not used by wlp-remote-8.5.

In our POM we expect it to be in a specific location that I was under the assumption will "never" change, but please check that, maybe that is the issue: arquillian-container-was/pom.xml at master · arquillian/arquillian-container-was · GitHub

Gerhard

Thanks, gpoul , for the quick reply!

The tools.jar is still found in the location from the link you included above. So that is safe. I tried adding that same dependency to my own parent POM, but then I am getting a different error:

org.jboss.arquillian.container.spi.client.container.LifecycleException: Could not start container

at org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer.start(WLPManagedContainer.java:194)

at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)

at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)

...

Caused by: java.io.IOException: input stream closed

at com.ibm.tools.attach.javaSE.AttachmentConnection.streamReceiveBytes(AttachmentConnection.java:49)

at com.ibm.tools.attach.javaSE.VirtualMachineImpl.getTargetProperties(VirtualMachineImpl.java:189)

at com.ibm.tools.attach.javaSE. VirtualMachineImpl .getSystemProperties(VirtualMachineImpl.java:173)

at ibm.tools.attach.J9VirtualMachine.getSystemProperties(J9VirtualMachine.java:52)

at org.jboss.arquillian.container.was.wlp_managed_8_5.WLPManagedContainer.getVMLocalConnectorAddress(WLPManagedContainer.java:220)

However, to my untrained eye, it almost looks like I may be getting farther past my original error. But I can't tell that for sure, I'm guessing, based on what I see above, and the use of the 'VirtualMachineImpl' class.. But I could very well be failing earlier because of that dependency I added.

Gerhard, to make a long story short, I had actually stumbled upon the solution to this before, but when I got this exception, I thought I had broken something. I added that tools.jar to the classpath in Maven, and got further. It seems the problem above was a permission issue in WebSphere Liberty Profile. Thanks for your help!

OK, cool. Does this mean you need the tools.jar in your project or is the dependency in our POM enough?

btw, I also tested this with the following version on one of my machines here:

Launching defaultServer (WebSphere Application Server 8.5.5.6/wlp-1.0.9.cl50620150610-1749 ) on IBM J9 VM, version pwa6470_27sr3fp1-20150605_01 (SR3 FP1) (en_US)

It worked on Windows as expected; What I found though when I looked at your version was an APAR IV71191 that talks about a NullPointerException in the Attach API. So maybe it would make sense to switch to SP3 anyway. But it works now, that's fine as well.

Gerhard

Gerhard, I just discovered something important by trying to run my coworker's code with the version of the container that I am using, and it got the same failure as I did.

I think I made a very bad assumption about the Arquillian code. We are using this dependency for Arquillian:

</dependency>

So in order to get around the problem with Arquillian not being able to delete the .war file, I checked out the '1.0.0.Beta2' branch of the code from Git, and changed that code to not throw an exception when it couldn't delete the file, and then added a call to deleteOnExit().

I made the assumption that the only difference between what I was running with, and what my teammates were running with, were the small changes I made. However, when my teammate's build failed when I tried to run it with my changes, it failed with this same exception of not being able to find the VirtualMachine class.

So I'm now suspecting that the code I changed really isn't the same as what we've been using all along, and that there are perhaps maybe some things in this code that aren't working. Does that give you any ideas?

Thanks again for all your help on this!

Hi Dave,

so I think the observation is that the code works on your coworkers machines, but it fails consistently (no matter whether it is your coworker's code or your's on your machine) - correct?

Which differences exactly are we talking  about? The differences between 1.0.0.Beta2 and the debug code I provided you with you can find at Comparing arquillian:1.0.0.Beta2...gpoul:ARQ-1961 · arquillian/arquillian-container-was · GitHub - the differences are only in the debug code even though I based this off the master branch; Beta2 is the most recent release.

Can you compare the java -fullversion between your coworker's machines and yours? Are they using the same or a different WLP?

But one more thing that might help: Given that maven caches local artifacts it could be that your coworkers have different maven artifacts cached than you and therefore the code runs with different dependencies on your machine than it does on your coworker's. Is that possibly also a point where there might be differences? You might want to use mvn dependency:tree as a starting point

On a machine where this is not working, you can try cleaning out your maven cache and retrying. If it still fails; would you be able to come up with a small test project that exhibits the same problem that you can share with me so I can potentially reproduce it?

Gerhard

I got this same error as a 'user error', also with a custom version of the Liberty Managed Container 8.5.

I forked the repo, cloned it locally, made my changes, mvn clean installed it and for me everything worked fine

locally...but I got the error above when submitting a 'batch' build to the shared build farm.

On investigation (this morning) it turns out that I had uploaded the custom Liberty Managed Container 8.5 to

our shared artifactory but had not uploaded the pom correctly. So the dependencies that the jar needed were not being

put on the class path and the tools.jar was the first one that was 'missed'.

For me it was a user error in the custom-pom deployment for the custom-jar

which had 'new' maven coordinates - just in case this is helpful to others if they have a similar situation.

Gordon