Skip to main content

java.awt.HeadlessException: No X11 DISPLAY

25 replies [Last post]
bernhasc
Offline
Joined: 2008-11-11
Points: 0

For the last several weeks, I've been trying to do an eval of JTHarness to use as part of a test suite/harness. I'm trying to integrate existing JUnit 4.x test cases into the harness. I thought the easiest way would be to wrap the JUnit class w/ a JTH class. When that wasn't working, I tried using the JUnitTestSuite, AnnotationFinder, etc. Eventually, I'll need to get this working w/ JUnit directly, but I can easily script the wrappers, so if I can get either method to work, I'll be happy.

I'm running RHESv4 w/ JTH v4.1.4, jre 1.6.0.10, and JUnit 4.5
-------------
% rpm -qa | grep jre
jre-1.6.0_10-fcs

% java -showversion
java version "1.6.0_10-rc"
Java(TM) SE Runtime Environment (build 1.6.0_10-rc-b28)
Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
-------------
JTHarness : jtharness-4_1_4-MR1-bin-b17-29_aug_2008.zip
-------------

When run from the command line, both the JUnit and JTH test classes run successfully; however, if I try to use the JTH GUI, I get the above error. Full text less the exception dump:
Failed. Unknown Exception Caught: java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it.

Run from Command line:
% echo $DISPLAY
:0.0
% echo $CP (base directory truncated to {test_dir} from : ~/bernhasc/Work/CxLCS/DocumentEditor)
{test_dir}/lib/jt-junit.jar:{test_dir}/lib/junit.jar:{test_dir}/dist/DocumentEditor.jar:{test_dir}/dist/lib:{test_dir}/build/classes:{test_dir}/build/test/classes:
% java -cp $CP documenteditor.MyAboutTest
closeAboutBox
OK
STATUS:Passed.OK
-----
(1st line is dumped by the JUnit test case).

I haven't been able to dig anything up on that exception wrt JTH.
------------------------------------------------
testsuite.jtt file:
# The presentation name of the test suite
name=Test Project 1.0 Test Suite (Tag Tests)
id=1.0
tests=test
# tests=build/test/classes

# The test finder to use
finder=com.sun.javatest.finder.TagTestFinder
# finder=com.sun.javatest.junit.JUnitAnnotationTestFinder

testsuite=com.sun.javatest.TestSuite
# testsuite=com.sun.javatest.junit.JUnitTestSuite

# The test script to use
script=com.sun.javatest.lib.StdTestScript
# script=com.sun.javatest.junit.JUnitAnnotationMultiTest
# script=com.sun.javatest.junit.JUnitTestRunner

# The jar file containing the test suite's JavaTest plug in classes
# classpath=
classpath=lib build/test/classes build/classes

# The configuration interview to use
interview=com.sun.javatest.interview.SimpleInterviewParameters
# interview=com.sun.javatest.junit.JUnitBaseInterview

# No keywords
# keywords=
------------------------------------------------
// MyAboutTest.java
package documenteditor;

import java.io.PrintWriter;
import com.sun.javatest.Status;
import com.sun.javatest.Test;

/**
* A test for com.sun.demoapi.lists.DoublyLinkedList.insert.
*
* @test
* @sources MyAboutTest.java
* @executeClass documenteditor.MyAboutTest
* @keywords About Dialog
*/
public class MyAboutTest implements Test
{
/**
* Standard command-line entry point.
* @param args command line args (ignored)
*/
public static void main(String[] args) {
PrintWriter err = new PrintWriter(System.err, true);
Test t = new MyAboutTest();
Status s = t.run(args, null, err);
s.exit();
}

/**
* Main test method. The test consists of a series of test cases;
* the test passes only if all the individual test cases pass.
* @param args ignored
* @param out ignored
* @param err a stream to which to write details about test failures
* @return a Status object indicating if the test passed or failed
*/
public Status run(String[] args, PrintWriter out, PrintWriter err) {
boolean ok = true;
int retval = 0xdeadbeef;
String message = "Test case failed";
DocumentEditorAboutBoxTest testCase = new DocumentEditorAboutBoxTest();

// save error stream to which to write error messages
this.err = err;

try {
retval = testCase.testCloseAboutBox();
} catch (NullPointerException e) {
retval = -1;
message = "Null Pointer Exception Caught";
} catch ( Exception e ) {
retval = -1;
message = "Unknown Exception Caught: " + e;
}

if (retval == 0) {
message = "OK";
err.println(message);
return Status.passed(message);
} else {
message = message + ": retval = " + retval;
err.println(message);
return Status.failed(message);
}
}

/**
* A stream to which to write info about test failures.
*/
private PrintWriter err;
}
------------------------------------------------
Directory listing of most of the relevant (and some irrelevant) files and directories:

./lib/javatest.jar
./lib/jt-junit.jar
./lib/jh.jar
./lib/asm.jar
./lib/DocumentEditor.jti
./lib/junit-4.5.jar
./lib/junit.jar -> ./lib/junit-4.5.jar
./dist/DocumentEditor.jar
./dist/lib/appframework-1.0.3.jar
./dist/lib/swing-worker-1.1.jar
./dist/lib/swing-layout-1.0.3.jar
./testsuite.jtt
./test/documenteditor/DocumentEditorAboutBoxTest.java
./test/documenteditor/DocumentEditorAppTest.java
./test/documenteditor/DocumenteditorSuite.java
./test/documenteditor/DocumentEditorViewTest.java
./test/documenteditor/MyAboutTest.java
./src/...
build/...
build/classes/...
build/classes/documenteditor/...
build/classes/documenteditor/resources/...
build/classes/documenteditor/resources/busyicons/...
build/classes/META-INF/...
build/classes/META-INF/services/...
build/test/...
build/test/classes/...
build/test/classes/documenteditor/...
build/test/results/...
./jt_harness/jtData/ResultCache2.jtw
./jt_harness/jtData/testsuite
./jt_harness/jtData/configHistory.jtl
./jt_harness/jtData/log.txt
./jt_harness/jtData/harness.trace
./jt_harness/jtData/lastRun.txt
./jt_harness/logfile.log
./jt_harness/documenteditor/MyAboutTest.jtr
------------------------------------------------
If you want the wrapped JUnit class, I can supply that as well as anything else I may have left out. I'm guessing I've got some tiny thing honked up someplace.

For the JUnitAnnotationTestFinder, I haven't had any luck getting to work either.
java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
bernhasc
Offline
Joined: 2008-11-11
Points: 0

Brian wrote:
> As for your classpath problem. Which classpath entry is it (org/jdesktop/application/ApplicationActionMap)
> supposed to be in? Perhaps /home/bernhasc/Work/CxLCS/DocumentEditor/lib supposed to
> point to a jar file, rather than just a directory?

That did it....dist/lib contained 3 jar files:
appframework-1.0.3.jar
swing-layout-1.0.3.jar
swing-worker-1.1.jar

Removing dist/lib and dist from the CP and replacing w/ the individual jar files fixed the remainder of the problems. The test FINALLY passed; I can move on to the next tool and flag this one as a keeper.

Jonathan Gibbons

If you were to ever run on Windows, you might need to set variables like
windir, SystemRoot, etc, depending on your flavor of Windows.

-- Jon

jtharness@mobileandembedded.org wrote:
> Since the display env could change from localhost:0.0 to somehost:14.0 (ssh -X -Y user@somehost), I suspect putting it in the description will not work for all cases. I'd prefer to put it in code and pick it up from the true environment (the System.getenv("DISPLAY") that Jon had mentioned in an earlier reply.
>
> Sergey wrote:
>
>> So, one of solutions is to write key=value pairs at the end of "command.execute" in
>> qCmdType.export method, after $testExecuteArgs,
>>
>
> Since I was able to repeat the error on command line, I decided to try the modified command line version 1st, before mucking with code.
>
> Executing the following command:
> % java -cp ./build/classes:./build/test/classes:$CP \ com.sun.javatest.lib.ExecStdTestOtherJVMCmd -v \
> DISPLAY=$DISPLAY /usr/java/latest/jre/bin/java -jar lib/javatest.jar
>
> Resulted in the following output (truncated) :
> Command is: /usr/java/latest/jre/bin/java -jar lib/javatest.jar
> Command environment is:
> DISPLAY=:0.0
>
> Followed by the JTH GUI being displayed. I'll now go in and modify the code (copy the SimpleInterviewParam class and rename to LCSInterviewParameters and make the suggested change (appending " DISPLAY="+System.getenv(Display) to the command string.
>
> As soon as I can verify that'll do the trick, I will mark the post as answered.
>
> Note: As far as I can tell, to get the widget instantiated, I only need DISPLAY passed thru.
>
> Asside: Maybe not modify SimpleInterviewParameters directly, but rather create a... SimpleGUIInterviewParameters class so 1) existing stuff doesn't risk being broken 2) Simple remains as simple as possible. For all Non-GUI tests, SIPconfigured everything I needed it to configure and, for the most part, did it quite well.
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316615
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

[att1.html]

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

Yup, good example.

And you wouldn't have DISPLAY problems on Windows...

bernhasc
Offline
Joined: 2008-11-11
Points: 0

After additional digging thru the ProcessCommand::exec(String[], String[], PrintWriter,PrintWriter) method, I found the -v option. This yielded some interesting results.
Seeing the output string "Command environment is:" led me to line 280 and the for-loop to display the contents of the env array. Seeing only the "=" in the next line took me back to line 266.
The cmdEnv is not null, but is 0 len, so it gets assigned a single element String array w/ value = {"="} ( approx lines: 266-268 from the latest subversion checkout w/o tags).

An asside: Lines 276-8 are dead code, since this condition is already handled and the array will be null length >= 1 at this point (see if block lines 266-268).

--------------- Transcript of run
% java -cp $CP com.sun.javatest.lib.ExecStdTestOtherJVMCmd -v /usr/java/latest/jre/bin/java -jar lib/javatest.jar
Command is: /usr/java/latest/jre/bin/java -jar lib/javatest.jar
Command environment is:
=
java.lang.ExceptionInInitializerError
at com.sun.javatest.tool.Desktop.(Desktop.java:157)
at com.sun.javatest.tool.Desktop.(Desktop.java:124)
at com.sun.javatest.tool.DesktopManager.createDesktop(DesktopManager.java:56)
at com.sun.javatest.tool.Main.run(Main.java:303)
at com.sun.javatest.tool.Main.main0(Main.java:140)
at com.sun.javatest.tool.Main.main(Main.java:120)
Caused by: java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at sun.awt.HeadlessToolkit.getScreenResolution(HeadlessToolkit.java:203)
at com.sun.javatest.tool.UIFactory.(UIFactory.java:3054)
... 6 more
STATUS:Failed.exit code 4
------------ EOT

My Q is, why would you want to pass in an env array w/ just the value "=" instead of passing in null and inheriting the env from the parent process? Will I need to subclass ProcessCommand to do this, then implement what's effectively a direct copy of the SimpleInterviewParameters class subing the cmd string for OTHER_VM to exec the new StdOtherVM class? Seems a bit... heavy, especially since I can get this thing to work from the command line w/o any of the wand-waving.

If I can get this to work, we'll be recommending the tool on an extremely high-visible NASA project (the LCS in the work directory above is Launch Control System).

Jonathan Gibbons

In other testing environments, we have found it to be better to limit
the set of environment variables
passed in to a child process, to limit the dependence on the user's
environment. Instead, we have
found it better to arrange so the test suite configuration takes care
of passing just those environment
variables that are known to be required.

In your case, I would suggest that you look at creating your own
subclass of SimpleInterview, extending
it so that the current value of the DISPLAY variable is passed to
ProcessCommand. I've not looked at
that code in a long while, but there should be some method like getEnv
that returns the environment used
to execute each test, and somewhere in the data for the environment
should the the parameters that get
passed to ProcessCommand.

[[ In case you're wondering, I'm just an alum of the team, and haven't
worked on this code for a while.
Hopefully one of the current members will step in with more
details... ]]

-- Jon G

On Nov 12, 2008, at 9:31 AM, jtharness@mobileandembedded.org wrote:

> After additional digging thru the ProcessCommand::exec(String[],
> String[], PrintWriter,PrintWriter) method, I found the -v option.
> This yielded some interesting results.
> Seeing the output string "Command environment is:" led me to line
> 280 and the for-loop to display the contents of the env array.
> Seeing only the "=" in the next line took me back to line 266.
> The cmdEnv is not null, but is 0 len, so it gets assigned a single
> element String array w/ value = {"="} ( approx lines: 266-268 from
> the latest subversion checkout w/o tags).
>
> An asside: Lines 276-8 are dead code, since this condition is
> already handled and the array will be null length >= 1 at this point
> (see if block lines 266-268).
>
> --------------- Transcript of run
> % java -cp $CP com.sun.javatest.lib.ExecStdTestOtherJVMCmd -v /usr/
> java/latest/jre/bin/java -jar lib/javatest.jar
> Command is: /usr/java/latest/jre/bin/java -jar lib/javatest.jar
> Command environment is:
> =
> java.lang.ExceptionInInitializerError
> at com.sun.javatest.tool.Desktop.(Desktop.java:157)
> at com.sun.javatest.tool.Desktop.(Desktop.java:124)
> at
> com
> .sun.javatest.tool.DesktopManager.createDesktop(DesktopManager.java:
> 56)
> at com.sun.javatest.tool.Main.run(Main.java:303)
> at com.sun.javatest.tool.Main.main0(Main.java:140)
> at com.sun.javatest.tool.Main.main(Main.java:120)
> Caused by: java.awt.HeadlessException:
> No X11 DISPLAY variable was set, but this program performed an
> operation which requires it.
> at
> sun.awt.HeadlessToolkit.getScreenResolution(HeadlessToolkit.java:203)
> at com.sun.javatest.tool.UIFactory.(UIFactory.java:
> 3054)
> ... 6 more
> STATUS:Failed.exit code 4
> ------------ EOT
>
> My Q is, why would you want to pass in an env array w/ just the
> value "=" instead of passing in null and inheriting the env from the
> parent process? Will I need to subclass ProcessCommand to do this,
> then implement what's effectively a direct copy of the
> SimpleInterviewParameters class subing the cmd string for OTHER_VM
> to exec the new StdOtherVM class? Seems a bit... heavy, especially
> since I can get this thing to work from the command line w/o any of
> the wand-waving.
>
> If I can get this to work, we'll be recommending the tool on an
> extremely high-visible NASA project (the LCS in the work directory
> above is Launch Control System).
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316342
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Hmm. guess I'm just a lil surprised that "out of the box" one cannot create a very basic GUI widget, a jUnit 4.1 test case for it and optionally a JTH test wrapper for that test case and have it work w/o all this hassle. All the non-GUI classes worked fine w/o any extra code written (except the JTH test class wrappers which I had scripted).

Thanks, Jon. I really appreciate all the help, esp since I am only remotely familiar w/ java (C, C++ here).

Jonathan Gibbons

Yes, I think the GUI test case is sufficiently interesting that it ought to
be accomodated. When SimpleInterview was written way back when,
I think the idea was to keep it as simple as possible, and arguably it
erred on the side of "too simple". Perhaps you should file an RFE against
JT Harness on their Issue Tracker on https://jtharness.dev.java.net/

If I get time, I might take a look at SimpleInterview to give you any
additional pointers.

By the way, the project you were talking about earlier sounded very cool.

-- Jon

jtharness@mobileandembedded.org wrote:
> Hmm. guess I'm just a lil surprised that "out of the box" one cannot create a very basic GUI widget, a jUnit 4.1 test case for it and optionally a JTH test wrapper for that test case and have it work w/o all this hassle. All the non-GUI classes worked fine w/o any extra code written (except the JTH test class wrappers which I had scripted).
>
> Thanks, Jon. I really appreciate all the help, esp since I am only remotely familiar w/ java (C, C++ here).
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316379
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

E-mail me at : s/\(com\)\(cctcorp\)\(bernhasc\)/\3at\2.\1/gp

Is there a better/differernt "canned" interview I should be using instead of Simple? Simple appeared to take care of everything. For a POC, I spoze I could hack the check for non-null-zero length cmdEnv and replace it w/ an assignment to null just to see what happens. All I'm after, for now, is a POC -- can this thing be used to drive suites that test both widget and non-widget classes.

Actually getting a full-fledged test suite harness up and running for their fledgling system is outside the scope. Simple definitely wont be sufficient for the final product -- too many configurable parameters will need to be set.

sergey_borodin
Offline
Joined: 2006-10-20
Points: 0

Sorry for delay...

Regarding SimpleInterviewParameters and issue #62 you filed - I'm agree that we may set values to some useful environment vars (anything else except DISPLAY?). The question is that SimpleInterviewParameters is not marked as demo implementation, and somebody may use it knowing its absolutely free from additional logics.

How to easy set up process environment for ExecStdTestOtherJVMCmd...

"export" method in SimpleInterviewParameters.qCmdType sets up "command.execute" variable.
For other VM execution it's value constructed in getOtherVMExecutionMethod. Command string has " $testExecuteClass $testExecuteArgs" suffix. Later they will be replaced with values of "executeClass" and "executeArgs" from TestDescription. Invokation chain is:
StdTestScript:123-127
Script.execute:805
Script.execute:818
Script.execute:860
....................
ProcessCommand.run

in ProcessCommand.run you may see that all the suffix of "command.execute", in format of
key1=val1 key2=val2 ...
is interpretted as set of environment var for new process.

So, one of solutions is to write key=value pairs at the end of "command.execute" in qCmdType.export method, after $testExecuteArgs, or to specify them in test description.

Hope my explanation will help,
Sergey

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Since the display env could change from localhost:0.0 to somehost:14.0 (ssh -X -Y user@somehost), I suspect putting it in the description will not work for all cases. I'd prefer to put it in code and pick it up from the true environment (the System.getenv("DISPLAY") that Jon had mentioned in an earlier reply.

Sergey wrote:
> So, one of solutions is to write key=value pairs at the end of "command.execute" in
> qCmdType.export method, after $testExecuteArgs,

Since I was able to repeat the error on command line, I decided to try the modified command line version 1st, before mucking with code.

Executing the following command:
% java -cp ./build/classes:./build/test/classes:$CP \ com.sun.javatest.lib.ExecStdTestOtherJVMCmd -v \
DISPLAY=$DISPLAY /usr/java/latest/jre/bin/java -jar lib/javatest.jar

Resulted in the following output (truncated) :
Command is: /usr/java/latest/jre/bin/java -jar lib/javatest.jar
Command environment is:
DISPLAY=:0.0

Followed by the JTH GUI being displayed. I'll now go in and modify the code (copy the SimpleInterviewParam class and rename to LCSInterviewParameters and make the suggested change (appending " DISPLAY="+System.getenv(Display) to the command string.

As soon as I can verify that'll do the trick, I will mark the post as answered.

Note: As far as I can tell, to get the widget instantiated, I only need DISPLAY passed thru.

Asside: Maybe not modify SimpleInterviewParameters directly, but rather create a... SimpleGUIInterviewParameters class so 1) existing stuff doesn't risk being broken 2) Simple remains as simple as possible. For all Non-GUI tests, SIPconfigured everything I needed it to configure and, for the most part, did it quite well.

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

I'll just add that we're completely open to accepting ideas like this and contributions of useful upgrades. I'm sure you've gathered that the current library classes are pretty basic. It would certainly not be a dis-service to start adding more robust or featured library classes - perhaps built upon the supplied ones.

As for providing pass-through env values - it's a bit difficult to anticipate what people would need for their particular situation, so providing a generic solution seems best as the next step.

P.S. What a discussion thread, thanks Jon for keeping up with it!

bernhasc
Offline
Joined: 2008-11-11
Points: 0

How about a Question similar to what you've done for the classpath Question in SIP?

instead of entering a single "value" such as "/opt/junit4.5/junit.jar" for a CP entry, the user could enter "DISPLAY=value" (expanded literally "DISPLAY=value") or "DISPLAY=$SYSENVVAR" (expanded as "DISPLAY=" + System.getenv("SYSENVVAR"))

----------------------------
Having issues w/ getting LCSInterviewParamenters working right. By appending DISPLAY= getenv("DISPLAY") after sb.append(" $testExecuteClass $testExecuteArgs"), I get the same [DISPLAY not set] exception; however, if I insert it just after the:
sb.append("com.sun.javatest.lib.ExecStdTestOtherJVMCmd ");
line, I got a different error (I also appended " -v "):
sb.append("com.sun.javatest.lib.ExecStdTestOtherJVMCmd ");
sb.append("-v ");
sb.append("DISPLAY="+System.getenv("DISPLAY") + " ");
-------------
produced the following outputs in the GUI:
[b]Summary:[/b] (empty)
[b]Messages:[/b] command: com.sun.javatest.lib.ExecStdTestOtherJVMCmd -v DISPLAY=:0.0 /usr/java/latest/jre/bin/java -classpath /home/bernhasc/Work/CxLCS/DocumentEditor/lib:/home/bernhasc/Work/CxLCS/DocumentEditor/dist:/home/bernhasc/Work/CxLCS/DocumentEditor/dist/lib:/home/bernhasc/Work/CxLCS/DocumentEditor/build/classes:/home/bernhasc/Work/CxLCS/DocumentEditor/build/test/classes documenteditor.MyAboutTest

[b]out 1 :[/b]
Command is: /usr/java/latest/jre/bin/java -classpath /home/bernhasc/Work/CxLCS/DocumentEditor/lib:/home/bernhasc/Work/CxLCS/DocumentEditor/dist:/home/bernhasc/Work/CxLCS/DocumentEditor/dist/lib:/home/bernhasc/Work/CxLCS/DocumentEditor/build/classes:/home/bernhasc/Work/CxLCS/DocumentEditor/build/test/classes documenteditor.MyAboutTest
Command environment is:
DISPLAY=:0.0
Exception in thread "main" java.lang.NoClassDefFoundError: org/jdesktop/application/ApplicationActionMap
at documenteditor.DocumentEditorAboutBoxTest.testCloseAboutBox(DocumentEditorAboutBoxTest.java:58)
at documenteditor.MyAboutTest.run(MyAboutTest.java:46)
at documenteditor.MyAboutTest.main(MyAboutTest.java:24)
Caused by: java.lang.ClassNotFoundException: org.jdesktop.application.ApplicationActionMap
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
... 3 more

[b]out 2 :[/b]
closeAboutBox
:0.0
JFrame Created

The JUnit Test function looks like :
public void testCloseAboutBox() {
System.out.println("closeAboutBox");
System.out.println(System.getenv("DISPLAY"));
[b]JFrame jpan = new JFrame("Close About Box Test");
System.out.println("JFrame Created");[/b]
instance = new DocumentEditorAboutBox(jpan); // [b]line 58[/b]
System.out.println("DocEd AboutBox Created. invoking closeAboutBox()");
instance.closeAboutBox();
System.out.println("closeAboutBox invoked.");
}

Edit(bernhasc) - Added line number intel

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

For entering DISPLAY, you were suggesting using the classpath interview question to inject the value? You could do this. But the current intention of the interview libraries is not that you can operate out of the box without writing any code.

The classpath thing is actually more complex than you think. If you went to Windows, you'd need to format the value differently for it to work. In other interviews that people have written, they go as far as asking what the separator values are, CLI flag names, etc. That way it can all be assembled correctly for whatever platform is in use. That's the high road.

The low road might be to ask the user to type the values needed for execution, perhaps using a StringListQuestion. Or if you know that you only need Windows and *NIX to work, you could do detection, ask what platform they want to configure for (and automatically transfer the DISPLAY or windir values), or even present a list of variables that can be transfered (overkill probably).

-----

As for your classpath problem. Which classpath entry is it (org/jdesktop/application/ApplicationActionMap) supposed to be in? Perhaps /home/bernhasc/Work/CxLCS/DocumentEditor/lib supposed to point to a jar file, rather than just a directory?

------

Also, as a style thing "Parameters" is a legacy term. Most of us are using class names like LCSInterview instead of LCDInterviewParameters now - it's shorter anyways. :)

Brian

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Thanks for all the attention you all are giving this thread. It's Greatly appriciated.

Brian wrote:
> For entering DISPLAY, you were suggesting using the classpath interview question
> to inject the value? You could do this. But the current intention of the interview
> libraries is not that you can operate out of the box without writing any code.

Well, I was thinkin more along the lines of a prompt / Question to ... poll .. the user for a list of env's s/he wants to manually set or import from the current/parent environment. Trying to think down the road and my past experiences w/ NASA and their under-development launch control systems. The last one, there were literally hundreds of env vars that needed to be set (each mission had it's own set of FD's and each delivery had a slightly different layout of the database as new features were integrated in). So there were env's specifying the release, another set specifying the mission params, DB format/layout, etc. Maybe that'd be better off in a flat-file properties file of some sort instead of an interview Q.......

-------------
Brian wrote:
> The classpath thing is actually more complex than you think. If you went to
> Windows, you'd need to format the value differently for it to work.
> [ chop ]
I had a key-value pair string list entry form of some sort where the "Add" added a prompted-string-line in the format of "KEY=VALUE" or "KEY=$ENVVAR" vs inserting a file/directory name. (I saw where "you" looped thru the line-items in the CP array and appended the separator after each item.)

> The low road might be to ask the user to type the values needed for execution,
> [chop]
> or even present a list of variables that can be transfered (overkill probably)
Hmm a multi-select box of all the env's detected? that could work.

-----
Brian wrote:
> As for your classpath problem. Which classpath entry is it (org/jdesktop/application/ApplicationActionMap)
> supposed to be in? Perhaps /home/bernhasc/Work/CxLCS/DocumentEditor/lib
> supposed to point to a jar file, rather than just a directory?

I have no earthly (or un-earthly, for that matter) idea where that came from. I'm neither using/referencing that class in any of the my test classes, nor is that classname referenced anywhere in the sample NB project. VERWAG didnt come up w/ anything useful on the subject.

------

> Also, as a style thing "Parameters" is a legacy term. Most of us are using class
> names like LCSInterview instead of LCSInterviewParameters now - it's shorter
> anyways.
Heh...Hear that. I copied it directly from what was in the svn checkout (SIP), then global replaced Simple->LCS and simple->lcs. Then, I ran the Simple->LCS in the jtt file. I was being lazy. :)

bkurotsu
Offline
Joined: 2004-12-13
Points: 0

Lots of good ideas...

If a flat file is natural for a lot of these settings, there's nothing wrong with doing it that way. It can actually make it more easy and lightweight to configure. Especially if you don't have that many settings that need to change regularly.

A design goal of JTH was to keep all configuration in the GUI - so the user didn't have to go find a terminal/editor to make changes. And doing in inside the config editor allowed error detection, etc.

In creating an interview, you could consider the number of settings that might every need to be changed. Then use a logical combination of flat files, interview questions which are pre-answered (either by detection or a default value) and questions which must be answered by the user.

Have you seen the PropertiesQuestion type? It allows a table presentation of many values in a single question.

Brian

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Running from Command line:
% java -cp $CP documenteditor.MyAboutTest
DISPLAY = :0.0
closeAboutBox
DISPLAY = :0.0
OK
STATUS:Passed.OK

Now from JTHarness :
DISPLAY = null
closeAboutBox
DISPLAY = null
Unknown Exception Caught: java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.

I tried changing the interview file from otherVM to sameVM, but it wouldnt load the configuration. Complained about Checksum; if I comment out the checksum line, it forces me back into the interview where the only options for running the test is other VM on same machine or agent on another machine.

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Well, I was able to repeat the error from command line while trying to start the JTHarness GUI via the ExecStdTestOtherJVMCmd class. Transcript follows. guess I'll dredge thru the src code and see if I can figure out wth ExecStdTestOtherJVMCmd is doing.

java -cp $CP com.sun.javatest.lib.ExecStdTestOtherJVMCmd /usr/java/latest/jre/bin/java -jar lib/javatest.jar
java.lang.ExceptionInInitializerError
at com.sun.javatest.tool.Desktop.(Desktop.java:157)
at com.sun.javatest.tool.Desktop.(Desktop.java:124)
at com.sun.javatest.tool.DesktopManager.createDesktop(DesktopManager.java:56)
at com.sun.javatest.tool.Main.run(Main.java:303)
at com.sun.javatest.tool.Main.main0(Main.java:140)
at com.sun.javatest.tool.Main.main(Main.java:120)
Caused by: java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at sun.awt.HeadlessToolkit.getScreenResolution(HeadlessToolkit.java:203)
at com.sun.javatest.tool.UIFactory.(UIFactory.java:3054)
... 6 more
STATUS:Failed.exit code 4

Jonathan Gibbons

The exception comes from JDK, not JTHarness. Try any/all of the following:

- google java.awt.headless
- set the system property java.awt.headless to true
- see http://java.sun.com/developer/technicalArticles/J2SE/Desktop/headless/

-- Jon G

jtharness@mobileandembedded.org wrote:
> For the last several weeks, I've been trying to do an eval of JTHarness to use as part of a test suite/harness. I'm trying to integrate existing JUnit 4.x test cases into the harness. I thought the easiest way would be to wrap the JUnit class w/ a JTH class. When that wasn't working, I tried using the JUnitTestSuite, AnnotationFinder, etc. Eventually, I'll need to get this working w/ JUnit directly, but I can easily script the wrappers, so if I can get either method to work, I'll be happy.
>
> I'm running RHESv4 w/ JTH v4.1.4, jre 1.6.0.10, and JUnit 4.5
> -------------
> % rpm -qa | grep jre
> jre-1.6.0_10-fcs
>
> % java -showversion
> java version "1.6.0_10-rc"
> Java(TM) SE Runtime Environment (build 1.6.0_10-rc-b28)
> Java HotSpot(TM) Server VM (build 11.0-b15, mixed mode)
> -------------
> JTHarness : jtharness-4_1_4-MR1-bin-b17-29_aug_2008.zip
> -------------
>
> When run from the command line, both the JUnit and JTH test classes run successfully; however, if I try to use the JTH GUI, I get the above error. Full text less the exception dump:
> Failed. Unknown Exception Caught: java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it.
>
>
> Run from Command line:
> % echo $DISPLAY
> :0.0
> % echo $CP (base directory truncated to {test_dir} from : ~/bernhasc/Work/CxLCS/DocumentEditor)
> {test_dir}/lib/jt-junit.jar:{test_dir}/lib/junit.jar:{test_dir}/dist/DocumentEditor.jar:{test_dir}/dist/lib:{test_dir}/build/classes:{test_dir}/build/test/classes:
> % java -cp $CP documenteditor.MyAboutTest
> closeAboutBox
> OK
> STATUS:Passed.OK
> -----
> (1st line is dumped by the JUnit test case).
>
> I haven't been able to dig anything up on that exception wrt JTH.
> ------------------------------------------------
> testsuite.jtt file:
> # The presentation name of the test suite
> name=Test Project 1.0 Test Suite (Tag Tests)
> id=1.0
> tests=test
> # tests=build/test/classes
>
> # The test finder to use
> finder=com.sun.javatest.finder.TagTestFinder
> # finder=com.sun.javatest.junit.JUnitAnnotationTestFinder
>
> testsuite=com.sun.javatest.TestSuite
> # testsuite=com.sun.javatest.junit.JUnitTestSuite
>
> # The test script to use
> script=com.sun.javatest.lib.StdTestScript
> # script=com.sun.javatest.junit.JUnitAnnotationMultiTest
> # script=com.sun.javatest.junit.JUnitTestRunner
>
> # The jar file containing the test suite's JavaTest plug in classes
> # classpath=
> classpath=lib build/test/classes build/classes
>
> # The configuration interview to use
> interview=com.sun.javatest.interview.SimpleInterviewParameters
> # interview=com.sun.javatest.junit.JUnitBaseInterview
>
> # No keywords
> # keywords=
> ------------------------------------------------
> // MyAboutTest.java
> package documenteditor;
>
> import java.io.PrintWriter;
> import com.sun.javatest.Status;
> import com.sun.javatest.Test;
>
> /**
> * A test for com.sun.demoapi.lists.DoublyLinkedList.insert.
> *
> * @test
> * @sources MyAboutTest.java
> * @executeClass documenteditor.MyAboutTest
> * @keywords About Dialog
> */
> public class MyAboutTest implements Test
> {
> /**
> * Standard command-line entry point.
> * @param args command line args (ignored)
> */
> public static void main(String[] args) {
> PrintWriter err = new PrintWriter(System.err, true);
> Test t = new MyAboutTest();
> Status s = t.run(args, null, err);
> s.exit();
> }
>
> /**
> * Main test method. The test consists of a series of test cases;
> * the test passes only if all the individual test cases pass.
> * @param args ignored
> * @param out ignored
> * @param err a stream to which to write details about test failures
> * @return a Status object indicating if the test passed or failed
> */
> public Status run(String[] args, PrintWriter out, PrintWriter err) {
> boolean ok = true;
> int retval = 0xdeadbeef;
> String message = "Test case failed";
> DocumentEditorAboutBoxTest testCase = new DocumentEditorAboutBoxTest();
>
> // save error stream to which to write error messages
> this.err = err;
>
> try {
> retval = testCase.testCloseAboutBox();
> } catch (NullPointerException e) {
> retval = -1;
> message = "Null Pointer Exception Caught";
> } catch ( Exception e ) {
> retval = -1;
> message = "Unknown Exception Caught: " + e;
> }
>
> if (retval == 0) {
> message = "OK";
> err.println(message);
> return Status.passed(message);
> } else {
> message = message + ": retval = " + retval;
> err.println(message);
> return Status.failed(message);
> }
> }
>
> /**
> * A stream to which to write info about test failures.
> */
> private PrintWriter err;
> }
> ------------------------------------------------
> Directory listing of most of the relevant (and some irrelevant) files and directories:
>
> ./lib/javatest.jar
> ./lib/jt-junit.jar
> ./lib/jh.jar
> ./lib/asm.jar
> ./lib/DocumentEditor.jti
> ./lib/junit-4.5.jar
> ./lib/junit.jar -> ./lib/junit-4.5.jar
> ./dist/DocumentEditor.jar
> ./dist/lib/appframework-1.0.3.jar
> ./dist/lib/swing-worker-1.1.jar
> ./dist/lib/swing-layout-1.0.3.jar
> ./testsuite.jtt
> ./test/documenteditor/DocumentEditorAboutBoxTest.java
> ./test/documenteditor/DocumentEditorAppTest.java
> ./test/documenteditor/DocumenteditorSuite.java
> ./test/documenteditor/DocumentEditorViewTest.java
> ./test/documenteditor/MyAboutTest.java
> ./src/...
> build/...
> build/classes/...
> build/classes/documenteditor/...
> build/classes/documenteditor/resources/...
> build/classes/documenteditor/resources/busyicons/...
> build/classes/META-INF/...
> build/classes/META-INF/services/...
> build/test/...
> build/test/classes/...
> build/test/classes/documenteditor/...
> build/test/results/...
> ./jt_harness/jtData/ResultCache2.jtw
> ./jt_harness/jtData/testsuite
> ./jt_harness/jtData/configHistory.jtl
> ./jt_harness/jtData/log.txt
> ./jt_harness/jtData/harness.trace
> ./jt_harness/jtData/lastRun.txt
> ./jt_harness/logfile.log
> ./jt_harness/documenteditor/MyAboutTest.jtr
> ------------------------------------------------
> If you want the wrapped JUnit class, I can supply that as well as anything else I may have left out. I'm guessing I've got some tiny thing honked up someplace.
>
> For the JUnitAnnotationTestFinder, I haven't had any luck getting to work either.
> java.lang.NoClassDefFoundError: org/objectweb/asm/ClassVisitor
> at java.lang.ClassLoader.defineClass1(Native Method)
> at java.lang.ClassLoader.defineClass(ClassLoader.java:621)
> at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316115
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Already read and tried those...
Running from command line, I get :
% java -Djava.awt.headless=true -cp $CP documenteditor.MyAboutTest
closeAboutBox
Unknown Exception Caught: java.awt.HeadlessException: retval = -1
STATUS:Failed.Unknown Exception Caught: java.awt.HeadlessException: retval = -1

MyAboutTest creates a JUnit test case which, in turn, creates a fairly vanilla "About" dialog box. IIRC, JPanel requires a connection to an X display even if it is not being setVisible(true). So, by forcing it headless, it tosses the HeadlessException.

The test runs correctly, if I don't run it via the GUI. If I setVisible(true) inside the JUnit test class (and run from CLI), the dialog box pops up and happily waits for me to click the "Close" button.

Edit (bernhasc): aded iirc Re: my JPanel comment.

Message was edited by: bernhasc

Jonathan Gibbons

Sorry, I got the sense of your headless problem the wrong way round.
Since you say the test works without using the JTHarness GUI, it sounds
like the basic GUI setup on your machine is OK. How are you running
the tests -- are you running them inside a new process? If so, make
sure you are propogating all the right env variables into the child process.

-- Jon G

jtharness@mobileandembedded.org wrote:
> Already read and tried those...
> Running from command line, I get :
> % java -Djava.awt.headless=true -cp $CP documenteditor.MyAboutTest
> closeAboutBox
> Unknown Exception Caught: java.awt.HeadlessException: retval = -1
> STATUS:Failed.Unknown Exception Caught: java.awt.HeadlessException: retval = -1
>
> MyAboutTest creates a JUnit test case which, in turn, creates a fairly vanilla "About" dialog box. JPanel requires a connection to an X display even if it is not being setVisible(true). So, by forcing it headless, it tosses the HeadlessException.
>
> The test runs correctly, if I don't run it via the GUI. If I setVisible(true) inside the JUnit test class (and run from CLI), the dialog box pops up and happily waits for me to click the "Close" button.
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316130
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Hmm. I used the SimpleInterviewParameters class and answered "In another process, on this machine" or something to that effect.

------------------------------
Answers to the Interview (lib/DocumentEditor.jti) :

#JT Harness Configuration Interview
#Tue Nov 11 10:12:12 EST 2008
CHECKSUM=30035de68de4bba5
DESCRIPTION=Test Configuration file for sample project DocumentEditor
INTERVIEW=com.sun.javatest.interview.SimpleInterviewParameters
LOCALE=en_US
NAME=DocumentEditor_testConfig
QUESTION=simple.epilog
TESTSUITE=/home/bernhasc/Work/CxLCS/DocumentEditor
WORKDIR=/home/bernhasc/Work/CxLCS/DocumentEditor/jt_harness
simple.classPath=/home/bernhasc/Work/CxLCS/DocumentEditor/lib/junit.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/lib/jt-junit.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/dist/DocumentEditor.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/build/test/classes
simple.cmdType=otherVM
simple.concurrency.concurrency=1
simple.desc=Test Configuration file for sample project DocumentEditor
simple.excludeList.latestAutoCheck=No
simple.excludeList.latestAutoCheckInterval=7
simple.excludeList.latestAutoCheckMode=everyXDays
simple.excludeList.needExcludeList=No
simple.jvm=/usr/java/latest/jre/bin/java
simple.keywords.keywords.mode=expr
simple.keywords.needKeywords=No
simple.name=DocumentEditor_testConfig
simple.priorStatus.needStatus=Yes
simple.priorStatus.status=error failed not_run
simple.tests.needTests=No
simple.tests.tests=
simple.tests.treeOrFile=tree
simple.timeout.timeout=1

Message was edited by: bernhasc

Jonathan Gibbons

I would guess the DISPLAY environment variable or something like that is
not being passed down to the child process. I'm not an expert on the
SimpleInterview, but I don't see anything in the interview file you gave
to indicate that env vars are being propogated.

If you want to check out this hypothesis, in your test program add a line
like
System.err.println(System.getenv());

-- Jon G

jtharness@mobileandembedded.org wrote:
> Hmm. I used the Std Simple Interview class and answered "In another process, on this machine" or something to that effect.
>
> ------------------------------
> Answers to the Interview (lib/DocumentEditor.jti) :
> #JT Harness Configuration Interview
> #Tue Nov 11 10:12:12 EST 2008
> CHECKSUM=30035de68de4bba5
> DESCRIPTION=Test Configuration file for sample project DocumentEditor
> INTERVIEW=com.sun.javatest.interview.SimpleInterviewParameters
> LOCALE=en_US
> NAME=DocumentEditor_testConfig
> QUESTION=simple.epilog
> TESTSUITE=/home/bernhasc/Work/CxLCS/DocumentEditor
> WORKDIR=/home/bernhasc/Work/CxLCS/DocumentEditor/jt_harness
> simple.classPath=/home/bernhasc/Work/CxLCS/DocumentEditor/lib/junit.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/lib/jt-junit.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/dist/DocumentEditor.jar\n/home/bernhasc/Work/CxLCS/DocumentEditor/build/test/classes
> simple.cmdType=otherVM
> simple.concurrency.concurrency=1
> simple.desc=Test Configuration file for sample project DocumentEditor
> simple.excludeList.latestAutoCheck=No
> simple.excludeList.latestAutoCheckInterval=7
> simple.excludeList.latestAutoCheckMode=everyXDays
> simple.excludeList.needExcludeList=No
> simple.jvm=/usr/java/latest/jre/bin/java
> simple.keywords.keywords.mode=expr
> simple.keywords.needKeywords=No
> simple.name=DocumentEditor_testConfig
> simple.priorStatus.needStatus=Yes
> simple.priorStatus.status=error failed not_run
> simple.tests.needTests=No
> simple.tests.tests=
> simple.tests.treeOrFile=tree
> simple.timeout.timeout=1
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316139
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

Unfortunately, I came to that same supposition last Wed, but thought it pointless to try to prove it since the error message claimed it wasn't set (... "No X11 DISPLAY variable was set"). Also, I assumed that spawned processes from a Java app would behave as expected wrt inheriting env's from the parent process; either that isn't a valid assumption, or JTH is resetting/eating the DISPLAY env for whatever reason -- possibly missing line item in either the .jtt or .jti file??. dunno.

When I get in tomorrow (~0830EST), I'll add that 1-liner and rerun.

Jonathan Gibbons

As a general statement about starting processes under JDK, you have the
option
of inheriting the env variables from the parent process, or not. IIRC,
in early JDK,
you could either inherit all the env variables, and not set any, or you
could
inherit none and set whatever you want. Anyway, the net result is that I
believe
SimpleInterview is not inheriting the env. I believe you need to extend the
interview to propogate DISPLAY into the child process. Arguably,
SimpleInterview
is too simple. Perhaps a current member of the JT Harness team could
comment...

Alternatively, can you change the answers to your questions to run your
tests
in the same VM as JT Harness, thereby avoiding the "new process" firewall?

-- Jon G.

jtharness@mobileandembedded.org wrote:
> Unfortunately, I came to that same supposition last Wed, but thought it pointless to try to prove it since the error message claimed it wasn't set (... "No X11 DISPLAY variable was set"). Also, I assumed that spawned processes from a Java app would behave as expected wrt inheriting env's from the parent process; either that isn't a valid assumption, or JTH is resetting/eating the DISPLAY env for whatever reason -- possibly missing line item in either the .jtt or .jti file??. dunno.
>
> When I get in tomorrow (~0830EST), I'll add that 1-liner and rerun.
> [Message sent by forum member 'bernhasc' (bernhasc)]
>
> http://forums.java.net/jive/thread.jspa?messageID=316171
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
> For additional commands, e-mail: interest-help@jtharness.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jtharness.dev.java.net
For additional commands, e-mail: interest-help@jtharness.dev.java.net

bernhasc
Offline
Joined: 2008-11-11
Points: 0

So :
From: simple.cmdType=otherVM
To: simple.cmdType=sameVM

?? Or is that wishful thinking on my part that that SWAG chg will do the trick?

Edit (bernhasc) - ate linebreak

Message was edited by: bernhasc

Message was edited by: bernhasc

Message was edited by: bernhasc

Message was edited by: bernhasc