It's all about the answers!

Ask a question

ClassDefNotFound with AntRunner build in JBE


Simon Fisher (1631710) | asked May 27 '10, 7:08 a.m.
JAZZ DEVELOPER
Hi,

I set up the JBE to run an Eclipse AntRunner build as described here: https://jazz.net/wiki/bin/view/Main/BuildAntRunner

This calls the AntRunner embedded in Websphere Message Broker Toolkit 7 (built on Eclipse 3.4.2), which then runs an snt script. We're using the Boker toolkit as we're doing JET transformations.

When we run the command on the command line on the build server, it runs the build successfully. However when run through the JBE command line build it fails with ClassDefNotFound exceptions, saying that it cannot find classes which are in JARs associated with the Broker Eclipse instance.

Any ideas on how to fix this?

Thanks,

Simon

8 answers



permanent link
Nick Edgar (6.5k711) | answered May 28 '10, 10:27 a.m.
JAZZ DEVELOPER
Hi Simon,

Are you using a Command Line build definition or an Ant one? It should be the former, since AntRunner runs on top of the Eclipse runtime (OSGi), Ant does not.

Are the command lines you use manually from the shell and configured in the build definition exactly the same?

Although it should not make a difference, you could also try setting the working directory in the build definition to be the same as the one you use when you invoke it manually.

permanent link
Simon Fisher (1631710) | answered May 28 '10, 10:49 a.m.
JAZZ DEVELOPER
Hi Nick,

Yes this is defined as a Command Line Build, directly calling the antRunner class from the Eclipse hierachy. The command line used manually and through JBE are exactly the same.

One interesting part of the build log says this:

2010-05-28 12:15:59 [Jazz build engine] Invoking build participant "com.ibm.team.build.cmdline"


The IBM Class Sharing Adaptor will not work in this configuration.

You are not running on J9.


The 'You are not running on J9 bit' worries me - we are currently using the IBM JDK 1.6 which is shipped with WebSphere Message Broker toolkit.

Any ideas on what the problem could be?

Simon

permanent link
Simon Fisher (1631710) | answered May 28 '10, 11:04 a.m.
JAZZ DEVELOPER
Also, output from java -version on the command line:

java version "1.6.0"

Java(TM) SE Runtime Environment (build pwi3260sr5ifix-20090824_02(SR5+IZ53892+IZ58949+IZ53194+IZ43801+IZ58796+IZ51441))

IBM J9 VM (build 2.4, J2RE 1.6.0 IBM J9 2.4 Windows Server 2003 x86-32 jvmwi3260sr5ifx-20090821_41076 (JIT enabled, AOT enabled)

J9VM - 20090821_041076_lHdSMr

JIT - r9_20090518_2017

GC - 20090417_AA)

JCL - 20090824_02

permanent link
Nick Edgar (6.5k711) | answered May 28 '10, 1:30 p.m.
JAZZ DEVELOPER
Is JBE being run with the same JVM? Do you have a -vm arg on the JBE command line, or in the jbe.ini? Do you get the same result using java -version from the home directory for JBE (or wherever you run it from)?

While we do recommend running JBE with the JDK included in the RTC client, I don't think it would explain the problem here, and you don't need to be worried about the class sharing warning.

> directly calling the antRunner class from the Eclipse hierachy
The command line should specify the antRunner application, not class name. Can you paste the command line you're using here?

permanent link
Nick Edgar (6.5k711) | answered Jun 05 '10, 10:44 a.m.
JAZZ DEVELOPER
Simon, just wondering whether you were able to resolve this issue.

permanent link
Simon Fisher (1631710) | answered Jun 09 '10, 6:36 a.m.
JAZZ DEVELOPER
Hi nick,

Interestingly we changed the command line build to execute a batch file which in turn called the antrunner. This worked as expected.

I'm a bit confused by this one - does the JBE not spawn a command window when starting a command line build? It seems it didn't get the right PATH / JAVA_HOME info, and was using the wrong JRE.

Thanks,

Simon

permanent link
Nick Edgar (6.5k711) | answered Jun 09 '10, 10:15 a.m.
JAZZ DEVELOPER
JBE does not spawn a command window, but the command that's run should work as if it was run from a command window. Well, there is one difference. 'Special' commands like dir and echo cannot be run directly, since these are not true executables but rather are interpreted by the command shell. You can get around with by configuring the build definition to run it under a command shell, e.g. cmd /c dir.

The environment should be the same whether you've configured it to run a batch file or an executable (i.e. java) directly. If you don't fully qualify the path to the java executable in the build definition, it should pick up the default one on the path. Any environment variables defined at the time you launched JBE should also be in effect. I've just verified that that's how java.lang.ProcessBuilder works on my Mac (and that's what's used by the command line build support in JBE). If you're seeing different behaviour on Windows, please open a bug report or let me know here.

You could also see if there's any difference in your case if you run java vs. cmd /c java.

permanent link
Nick Edgar (6.5k711) | answered Jun 09 '10, 10:20 a.m.
JAZZ DEVELOPER
Just FYI, the program I used to check ProcessBuilder is:

import java.io.IOException;
import java.io.InputStream;
import java.io.InputStreamReader;
import java.util.Map;

public class ProcessBuilderTest {

public static void main(String[] args) throws IOException {
ProcessBuilder builder = new ProcessBuilder("java");
for (Map.Entry<String, String> entry : builder.environment().entrySet()) {
System.out.println(entry.getKey() + " = " + entry.getValue());
}
builder.redirectErrorStream();
Process process = builder.start();
InputStream stream = process.getInputStream();
InputStreamReader reader = new InputStreamReader(stream);
char[] buf = new char[8192];
int read;
while ((read = reader.read(buf)) != -1) {
System.out.print(new String(buf, 0, read));
}
reader.close();
}
}


It printed out my environment variables, and also the java command usage, indicating it was able to find java on the path.

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.