AS testsuite using wrong jvm to exectute tests?

[emuckenhuber]

I noticed that when running tests in the AS testsuite the jvm used to run the junit tests seems to be wrong.

There is a property called ${junit.jvm} which is never set. The default value of this is just "java".
Although it should use the one specified in $JAVA_HOME instead the one found on the $PATH.

Basically i use jdk5 to compile and run AS and the tests. But it then executes the test itself
with openjdk 1.6. This leads to some annoying behavior - e.g. failing tests, because of a serialVersionUID change in a sun class.

Can someone fix that for all jdks and OSes? As i could just test that for my local installation :)

I mean i can workaround that for the moment setting ANT_OPTS="-Djunit.jvm=/path/to/my/jdk",
but i guess this could also affect the hudson runs at one point.

[akostadinov]

In my experience, to use java reliably, you need to have JAVA_HOME set to the jdk/jre directory.

AFAIU you, you are running Sun JVM to compile AS and tests but you are running it with JAVA_HOME set to the openjdk location. Is that correct? I don't think that can work properly. It could if you have -Djava.home=<jdk.path>/jre.
But in this case wouldn't it be easier to just set -Djunit.jvm ?

[emuckenhuber]

"akostadinov" wrote:
In my experience, to use java reliably, you need to have JAVA_HOME set to the jdk/jre directory.

AFAIU you, you are running Sun JVM to compile AS and tests but you are running it with JAVA_HOME set to the openjdk location. Is that correct? I don't think that can work properly. It could if you have -Djava.home=<jdk.path>/jre.
But in this case wouldn't it be easier to just set -Djunit.jvm ?

I have JAVA_HOME pointing to my jdk directory. So AS is compiled and run with this jdk.
The only problem is that JAVA_HOME is not used for junit tests. The one on the system $PATH is used,
as the default value of ${junit.jvm} is net setUp propery.

This means in my case that JAVA_HOME is pointing to my sun-jdk-1.5 and
the junit test is run with openjdk 1.6 (as this is the one in my system $PATH),
although it should use the one from JAVA_HOME.

So i have to set this ${junit.jvm} property to get "[testsuite]$ ./build.sh tests-profileservice" working.
Just because it's using the wrong jdk :)

[emuckenhuber]

To illustrate that a bit:

if i run:
[testsuite]$ sh build.sh one-test -Dtest=org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase

it's failing with:
[junit] java.io.InvalidClassException: sun.reflect.annotation.AnnotationInvocationHandler; local class incompatible: stream classdesc serialVersionUID = 6182022883658399397, local class serialVersionUID = 3194649965547556111)

The same with:
[testsuite]$ sh build.sh one-test -Dtest=org.jboss.test.profileservice.override.test.JmsDestinationOverrideTestCase -Djunit.jvm=$JAVA_HOME/bin/java

passes as expected.

[akostadinov]

I see what is the case now. build.sh and ant construct java executable location based on JAVA_HOME environment variable where junit relies on PATH being set correctly.

That should never be a problem for hudson, because it always sets both - JAVA_HOME and PATH. As well our QA scripts do the same when changing java version.

It makes some sense to have junit.jvm property default to JAVA_HOME/... but see the logic in ant.sh to guess the java executable location. As well there are often cases where JAVA_HOME is not set (AFAIK when user is using the default jvm installed with the OS and probably on systems like azul).
It should be possible to change it to:
1. if JAVA_HOME is not set, then set to "java"
2. if JAVA_HOME is set, then to setup like ant.sh does

But actually I think it is better to check if the first java executable in PATH is within JAVA_HOME, and if not, then fail the build. I'm sure everybody happened to mismatch these a couple of times, so saved hassle could be considerable.

[emuckenhuber]

"akostadinov" wrote:

That should never be a problem for hudson, because it always sets both - JAVA_HOME and PATH. As well our QA scripts do the same when changing java version.

okay good to know :)

"akostadinov" wrote:

It makes some sense to have junit.jvm property default to JAVA_HOME/... but see the logic in ant.sh to guess the java executable location.

Yes, how about adding this in tools/bin/ant - because there you already have the logic for calling ant with the correct jdk:

ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS
-classpath \"$LOCALCLASSPATH\" -Dant.home=\"$ANT_HOME\"
-Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts org.apache.tools.ant.launch.Launcher $ANT_ARGS
-cp \"$CLASSPATH\" $ant_exec_args"

So you can add -Djunit.jvm= $JAVACMD - then you use the same jdk calling ant :)

[akostadinov]

"emuckenhuber" wrote:

ant_exec_command="exec \"$JAVACMD\" $ANT_OPTS
-classpath \"$LOCALCLASSPATH\" -Dant.home=\"$ANT_HOME\"
-Dant.library.dir=\"$ANT_LIB\" $ant_sys_opts org.apache.tools.ant.launch.Launcher $ANT_ARGS
-cp \"$CLASSPATH\" $ant_exec_args"

So you can add -Djunit.jvm= $JAVACMD - then you use the same jdk calling ant :)

That sounds like a better solution but I still see concerns about tests themselves forking by just executing "java". So I still prefer the check if PATH and JAVA_HOME match and fail otherwise.

Others might think differently though.

[emuckenhuber]

"akostadinov" wrote:

That sounds like a better solution but I still see concerns about tests themselves forking by just executing "java".

Well that's why it should be based on the junit.jvm property - as it has the default value "java".
If it's not set it would fallback to the one on the PATH. And just execution "java" seems wrong to me.

"akostadinov" wrote:

So I still prefer the check if PATH and JAVA_HOME match and fail otherwise.

Well this basically breaks the main benefit for me using JAVA_HOME - so that i can easily switch jdks for testing.
Requiring that jdk5 is the first java entry in my PATH would make some other java based apps unusable requiring jdk6.
For example the eclipse which comes bundled fedora - not sure about the java plugin for firefox...