Details

    • Type: Test Test
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: build
    • Labels:
      None
    • Environment:

      JDK 1.5 or later with jtreg test suite http://www.openjdk.org/jtreg/

      Description

      From a recent discussion on river-dev:

      Peter Firmstone wrote:
      > Using the GPLv2 version of jtreg is ok as a platform requirement for the tests, we just can't distribute it with River.
      >
      > Peter Jones wrote:
      >> On Tue, Apr 21, 2009 at 06:27:18PM +0200, Jonathan Costers wrote:
      >>
      >>> Something a bit off-topic: the "jtreg tests" are mentioned in the
      >>> discussion you linked to. How do these differ from the other harness/QA
      >>> tests? I must say I haven't really looked at them deeply, but I did
      >>> notice them and that they are separate from the QA suite ...
      >>> For the moment the source just sits there .. Nothing is even compiled.
      >>> Would you be able to give some pointers?
      >>>
      >>
      >> Sure. They are written to be run with "jtreg", the test harness used
      >> for regression & unit tests for Sun's JDK. These days there is a
      >> version of jtreg available under GPLv2 as part of the OpenJDK project,
      >> here:
      >>
      >> http://www.openjdk.org/jtreg/
      >>
      >> The use of this test framework in addition to the primary Jini QA
      >> framework is historical: some of the APIs added to version 2.0 of the
      >> Jini starter kit-- such as JERI and the related security model,
      >> preferred classes, the configuration stuff-- were originally developed
      >> for the JDK, mostly under JSRs 76 & 78, and thus their implementations
      >> initially had tests written for the jtreg framework. When those APIs
      >> and implementations were moved to the Jini starter kit, those jtreg
      >> tests came with them, and some new tests in those areas continued to
      >> be added to this jtreg suite.
      >>
      >> The essential jtreg model is very simple: a test is a tagged class
      >> (source file) with a normal "main" method-- if that method completes
      >> normally, the test passes; if it throws an exception (or times out, or
      >> the JVM crashes...), the test fails. The jtreg goal was to set a very
      >> low barrier to move standalone test cases or example code into the
      >> framework. The framework does specify more options and nuances, but
      >> it's still pretty simple overall:
      >>
      >> http://www.openjdk.org/jtreg/tag-spec.txt
      >>
      >> which is quite nice for some things-- of course it doesn't have
      >> anything like the power of the Jini QA framework for testing of
      >> distributed services, etc. And the Jini jtreg suite has accreted an
      >> unfortunately somewhat ad hoc infrastructure library of its own, in
      >> the "qa/jtreg/testlibrary" directory. Also, I think that it still has
      >> a few assumptions about being run within Sun's internal network, like
      >> that certain services (a KDC?) are provided by certain host names.
      >>
      >> You just see source files because the harness is responsible for
      >> building them at test execution time. The jtreg implementation is
      >> built as a layer on top of the JavaTest framework (a much more complex
      >> test framework used for the JCK among other things), which has the
      >> same build-at-test-execution-time model. (This is nice in that
      >> breaking the compilation of one test doesn't prevent executing other,
      >> unaffected tests-- each test is isolated all the way to its source.)
      >>
      >> I'm not sure how the GPLv2 status of the jtreg implementation
      >> available through the OpenJDK project affects the ability to use it to
      >> run these tests for River. A nice aspect of the jtreg model's
      >> simplicity is that the test classes themselves do not need to link to
      >> or otherwise refer to any test framework APIs-- there are no such
      >> APIs. (In theory each of these tests can be run as is, with the right
      >> class paths and javac & java commands.) At one time the engineering
      >> lead for the Jini QA harness had prototyped adding support for
      >> jtreg-style tests to the Jini harness, and I think that he had gotten
      >> it more or less working, but that effort was dropped for reasons I
      >> can't recall-- although I would guess that it didn't seem like a
      >> priority at the time because jtreg itself was available internally.
      >>
      >> – Peter
      >>
      >>

      1. ant.html
        8 kB
        Peter Firmstone
      2. jtreg_stdout_errout.txt
        406 kB
        Peter Firmstone
      3. jtreg-20100827-JC.log
        37 kB
        Jonathan Costers
      4. jtreg-output-20090928-JC.tar.gz
        90 kB
        Jonathan Costers
      5. JTreport.tgz
        26 kB
        Peter Firmstone
      6. JTreport-jdk1.5-qatests-trunk.tgz
        14 kB
        Peter Firmstone
      7. JTwork.tgz
        1.01 MB
        Peter Firmstone
      8. JTwork-jdk5-qatests-trunk.tgz
        998 kB
        Peter Firmstone
      9. test-results6-oct-09.tgz
        1.21 MB
        Peter Firmstone

        Issue Links

          Activity

          Hide
          Jonathan Costers added a comment -

          I just ran the complete jtreg suite again (complete log attached):

          Test results: passed: 128; failed: 10

          Show
          Jonathan Costers added a comment - I just ran the complete jtreg suite again (complete log attached): Test results: passed: 128; failed: 10
          Hide
          Peter Firmstone added a comment -

          Hi Jonathan,

          You must still have the jar files in your jre/lib/ext/ directory? Or
          have you edited the policy files?

          I'm want to commit several changes, however I'm still getting some
          breakages. Only 100 tests will pass until I track down all the
          dependencies (test.props appears to be accessed from places other than
          TestLibrary.java although I'm not 100% certain that is the case, I'm
          sure I searched for test.props)

          I'm removing the dependency on test.props so all options can be
          specified in the build.xml file. The other change is the AllPermission
          addition to all policy files that had AllPermission to access the
          jre/lib/ext/ directory.

          Cheers,

          Peter.

          Show
          Peter Firmstone added a comment - Hi Jonathan, You must still have the jar files in your jre/lib/ext/ directory? Or have you edited the policy files? I'm want to commit several changes, however I'm still getting some breakages. Only 100 tests will pass until I track down all the dependencies (test.props appears to be accessed from places other than TestLibrary.java although I'm not 100% certain that is the case, I'm sure I searched for test.props) I'm removing the dependency on test.props so all options can be specified in the build.xml file. The other change is the AllPermission addition to all policy files that had AllPermission to access the jre/lib/ext/ directory. Cheers, Peter.
          Hide
          Peter Firmstone added a comment -

          I've altered my copy locally so property's can be specified in ant and pass through jtreg to the test using the -D option. I've obviously missed some property files and accessors to test.props

          I'll commit what I've done to date and continue with the work.

          Oddly enough I'm getting a number of the following access failures

          [jtreg] java.security.AccessControlException: access denied (java.io.FilePermission /opt/src/ApacheRiver/trunk/qa/jtreg/com/sun/jini/tool/CheckConfigurationFile/config-no-perm read)
          [jtreg] access: access denied (java.util.PropertyPermission user.timezone write)
          [jtreg] access: access denied (java.lang.RuntimePermission accessClassInPackage.sun.util.logging.resources)

          Will look into it further shortly.

          Show
          Peter Firmstone added a comment - I've altered my copy locally so property's can be specified in ant and pass through jtreg to the test using the -D option. I've obviously missed some property files and accessors to test.props I'll commit what I've done to date and continue with the work. Oddly enough I'm getting a number of the following access failures [jtreg] java.security.AccessControlException: access denied (java.io.FilePermission /opt/src/ApacheRiver/trunk/qa/jtreg/com/sun/jini/tool/CheckConfigurationFile/config-no-perm read) [jtreg] access: access denied (java.util.PropertyPermission user.timezone write) [jtreg] access: access denied (java.lang.RuntimePermission accessClassInPackage.sun.util.logging.resources) Will look into it further shortly.
          Hide
          Jonathan Costers added a comment -

          I don't know exactly what went wrong before .. maybe I was using a stale JTwork directory?

          But in any case .. I did a clean run (deleting the JT* directories first) of the jtreg tests, both using the command line as from Ant, and both passed:

          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup
          Test results: passed: 1
          Report written to JTreport/html/report.html
          Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork

          and from Ant, running the whole suite:

          [jtreg] Test results: passed: 132; failed: 6
          [jtreg] Report written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTreport/html/report.html
          [jtreg] Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork
          [jtreg] Error: Some tests failed or other problems occurred.

          Show
          Jonathan Costers added a comment - I don't know exactly what went wrong before .. maybe I was using a stale JTwork directory? But in any case .. I did a clean run (deleting the JT* directories first) of the jtreg tests, both using the command line as from Ant, and both passed: jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup Test results: passed: 1 Report written to JTreport/html/report.html Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork and from Ant, running the whole suite: [jtreg] Test results: passed: 132; failed: 6 [jtreg] Report written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTreport/html/report.html [jtreg] Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork [jtreg] Error: Some tests failed or other problems occurred.
          Hide
          Peter Jones added a comment -

          This test infrastructure code (testlibrary/HTTPD.java) is not designed to expect that tools.jar is in the JRE extensions directory, so it shouldn't be necessary.

          Are you sure that "/home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar" exists? The "HTTPD:" debug line doesn't confirm the existence of the file-- it just indicates where the HTTPD's class loader is going to look for it. (The path is computed by concatenating the value of the "jsk.home" value from the "test.props" file with "/lib/tools.jar", although using the platform-appropriate file separator.)

          Show
          Peter Jones added a comment - This test infrastructure code (testlibrary/HTTPD.java) is not designed to expect that tools.jar is in the JRE extensions directory, so it shouldn't be necessary. Are you sure that "/home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar" exists? The "HTTPD:" debug line doesn't confirm the existence of the file-- it just indicates where the HTTPD's class loader is going to look for it. (The path is computed by concatenating the value of the "jsk.home" value from the "test.props" file with "/lib/tools.jar", although using the platform-appropriate file separator.)
          Hide
          Jonathan Costers added a comment -

          My user account should be able to do that, since i've been running QA tests successfully:

          ============================== CALLING SETUP() ==============================
          4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run
          INFO: ClassServer started [[/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/lib/], port 8081]
          4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run
          INFO: ClassServer started [[/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/lib-dl/], port 8080]
          4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run
          INFO: ClassServer started [[/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/lib/], port 8082]

          I'll rerun with java.security.debug property and port the results. I'll have to wait for a bunch of QA tests to finish though.. That may take a cpl hours.

          Thanks
          Jonathan

          Show
          Jonathan Costers added a comment - My user account should be able to do that, since i've been running QA tests successfully: ============================== CALLING SETUP() ============================== 4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run INFO: ClassServer started [ [/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/lib/] , port 8081] 4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run INFO: ClassServer started [ [/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/lib-dl/] , port 8080] 4-okt-2009 13:11:07 com.sun.jini.tool.ClassServer run INFO: ClassServer started [ [/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/lib/] , port 8082] I'll rerun with java.security.debug property and port the results. I'll have to wait for a bunch of QA tests to finish though.. That may take a cpl hours. Thanks Jonathan
          Hide
          Peter Firmstone added a comment -

          Adding tools.jar to the jre/lib/ext directory grants it AllPermission, via the jvm, so it has the privileges of the jvm process. Perhaps your user account doesn't have permission to create the port on 8081?

          Can you add this argument to your command: -Djava.security.debug=access,failure

          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun -Djava.security.debug=access,failure net/jini/activation/Activatable/inactiveGroup

          and post the results, if it's a permission problem it'll definitely show it.

          This line in your output indicates that the test is certainly finding the tools.jar file:
          HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib-dl

          Cheers,

          Peter.

          Show
          Peter Firmstone added a comment - Adding tools.jar to the jre/lib/ext directory grants it AllPermission, via the jvm, so it has the privileges of the jvm process. Perhaps your user account doesn't have permission to create the port on 8081? Can you add this argument to your command: -Djava.security.debug=access,failure jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun -Djava.security.debug=access,failure net/jini/activation/Activatable/inactiveGroup and post the results, if it's a permission problem it'll definitely show it. This line in your output indicates that the test is certainly finding the tools.jar file: HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib-dl Cheers, Peter.
          Hide
          Jonathan Costers added a comment -

          OK, a very silly mistake...
          I found a typo in my test.props file: was using jstk instead of jtsk in the jsk.home path ...
          That fixes phoenix.jar not being found in above comment (tested running the command manually as you suggested Peter).

          However, I have another question/issue:

          In the list of River JARs to be put in jre/lib/ext, I noticed there is no tools.jar mentioned. If I don't move tools.jar there or add it to jtreg's classpath, I get following output, basically saying it cannot find ClassServer ...

          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup
          Directory "JTreport" not found: creating
          Directory "JTwork" not found: creating
          Directory "JTwork/scratch" not found: creating
          --------------------------------------------------
          TEST: net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java
          JDK under test: (/usr/lib/jvm/java-1.5.0-sun)
          java version "1.5.0_19"
          Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02)
          Java HotSpot(TM) Server VM (build 1.5.0_19-b02, mixed mode)

          ACTION: build – Passed. Build successful
          REASON: User specified action: run build TestLibrary RMID ActivationLibrary
          TIME: 0.995 seconds
          messages:
          command: build TestLibrary RMID ActivationLibrary
          reason: User specified action: run build TestLibrary RMID ActivationLibrary
          elapsed time (seconds): 0.995

          ACTION: compile – Passed. Compilation successful
          REASON: .class file out of date or does not exist
          TIME: 0.989 seconds
          messages:
          command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/TestLibrary.java /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/RMID.java /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/ActivationLibrary.java
          reason: .class file out of date or does not exist
          elapsed time (seconds): 0.989
          STDOUT:
          STDERR:
          Note: Some input files use unchecked or unsafe operations.
          Note: Recompile with -Xlint:unchecked for details.

          ACTION: build – Passed. Build successful
          REASON: User specified action: run build ActivateMe
          TIME: 0.535 seconds
          messages:
          command: build ActivateMe
          reason: User specified action: run build ActivateMe
          elapsed time (seconds): 0.535

          ACTION: compile – Passed. Compilation successful
          REASON: .class file out of date or does not exist
          TIME: 0.535 seconds
          messages:
          command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/ActivateMe.java
          reason: .class file out of date or does not exist
          elapsed time (seconds): 0.535
          STDOUT:
          STDERR:

          ACTION: build – Passed. Build successful
          REASON: User specified action: run build InactiveGroup
          TIME: 0.64 seconds
          messages:
          command: build InactiveGroup
          reason: User specified action: run build InactiveGroup
          elapsed time (seconds): 0.64

          ACTION: compile – Passed. Compilation successful
          REASON: .class file out of date or does not exist
          TIME: 0.64 seconds
          messages:
          command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java
          reason: .class file out of date or does not exist
          elapsed time (seconds): 0.64
          STDOUT:
          STDERR:

          ACTION: build – Passed. Build successful
          REASON: User specified action: run build InactiveGroup_Stub
          TIME: 0.589 seconds
          messages:
          command: build InactiveGroup_Stub
          reason: User specified action: run build InactiveGroup_Stub
          elapsed time (seconds): 0.589

          ACTION: compile – Passed. Compilation successful
          REASON: .class file out of date or does not exist
          TIME: 0.588 seconds
          messages:
          command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/InactiveGroup_Stub.java
          reason: .class file out of date or does not exist
          elapsed time (seconds): 0.588
          STDOUT:
          STDERR:

          ACTION: build – Passed. All files up to date
          REASON: Named class compiled on demand
          TIME: 0.0 seconds
          messages:
          command: build InactiveGroup
          reason: Named class compiled on demand
          elapsed time (seconds): 0.0

          ACTION: main – Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          REASON: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup
          TIME: 5.726 seconds
          messages:
          command: main -Dtest.rmi.exportType=defaultInactiveGroup
          reason: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup
          elapsed time (seconds): 5.726
          STDOUT:

          Regression test for bug 4116082

          STDERR:
          exportType: default
          HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib-dl
          TEST FAILED:
          Test failed with: oops
          java.io.IOException: oops
          at HTTPD.<init>(HTTPD.java:111)
          at HTTPD.<init>(HTTPD.java:71)
          at RMID.start(RMID.java:184)
          at RMID.start(RMID.java:171)
          at InactiveGroup.main(InactiveGroup.java:107)
          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:585)
          at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
          at java.lang.Thread.run(Thread.java:595)
          Caused by: java.lang.ClassNotFoundException: com.sun.jini.tool.ClassServer
          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:306)
          at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
          at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
          at java.lang.Class.forName0(Native Method)
          at java.lang.Class.forName(Class.java:242)
          at HTTPD$Daemon$1.run(HTTPD.java:169)
          at java.security.AccessController.doPrivileged(Native Method)
          at HTTPD$Daemon.create(HTTPD.java:163)
          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:585)
          at HTTPD.<init>(HTTPD.java:94)
          ... 10 more
          ACTIVATION_LIBRARY: tried to shutdown when rmid was not running
          TEST FAILED: rmid not destroyed in: 60000 milliseconds
          TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          at TestLibrary.bomb(TestLibrary.java:92)
          at TestLibrary.bomb(TestLibrary.java:95)
          at ActivationLibrary.rmidCleanup(ActivationLibrary.java:195)
          at InactiveGroup.main(InactiveGroup.java:188)
          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:585)
          at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
          at java.lang.Thread.run(Thread.java:595)

          JavaTest Message: Test threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          JavaTest Message: shutting down test

          STATUS:Failed.`main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds

          TEST RESULT: Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          --------------------------------------------------
          Test results: failed: 1
          Report written to JTreport/html/report.html
          Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork
          Error: Some tests failed or other problems occurred.

          Contents of jre/lib/ext:
          --------------------------------
          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ ls -al /usr/lib/jvm/java-1.5.0-sun/jre/lib/ext
          totaal 2408
          drwxr-xr-x 2 root root 4096 2009-10-04 11:53 .
          drwxr-xr-x 18 root root 4096 2009-10-01 23:53 ..
          rw-rr- 1 root root 8215 2009-05-04 12:01 dnsns.jar
          rw-rr- 1 root root 246722 2009-10-04 11:10 jsk-lib.jar
          rw-rr- 1 root root 796635 2009-10-04 11:10 jsk-platform.jar
          rw-rr- 1 root root 24691 2009-10-04 11:10 jsk-policy.jar
          rw-rr- 1 root root 3939 2009-10-04 11:12 jsk-resources.jar
          rw-rr- 1 root root 810816 2009-07-15 08:54 localedata.jar
          rw-rr- 1 root root 2257 2009-10-04 11:10 phoenix-init.jar
          rw-rr- 1 root root 158419 2009-05-04 11:53 sunjce_provider.jar
          rw-rr- 1 root root 175949 2009-05-04 11:53 sunpkcs11.jar

          If I copy tools.jar into jre/lib/ext, the test passes fine:

          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup
          Directory"JTreport" not found: creating
          Directory "JTwork" not found: creating
          Directory "JTwork/scratch" not found: creating
          Test results: passed: 1
          Report written to JTreport/html/report.html
          Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork

          Any suggestions?

          Thanks
          Jonathan

          Show
          Jonathan Costers added a comment - OK, a very silly mistake... I found a typo in my test.props file: was using jstk instead of jtsk in the jsk.home path ... That fixes phoenix.jar not being found in above comment (tested running the command manually as you suggested Peter). However, I have another question/issue: In the list of River JARs to be put in jre/lib/ext, I noticed there is no tools.jar mentioned. If I don't move tools.jar there or add it to jtreg's classpath, I get following output, basically saying it cannot find ClassServer ... jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup Directory "JTreport" not found: creating Directory "JTwork" not found: creating Directory "JTwork/scratch" not found: creating -------------------------------------------------- TEST: net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java JDK under test: (/usr/lib/jvm/java-1.5.0-sun) java version "1.5.0_19" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02) Java HotSpot(TM) Server VM (build 1.5.0_19-b02, mixed mode) ACTION: build – Passed. Build successful REASON: User specified action: run build TestLibrary RMID ActivationLibrary TIME: 0.995 seconds messages: command: build TestLibrary RMID ActivationLibrary reason: User specified action: run build TestLibrary RMID ActivationLibrary elapsed time (seconds): 0.995 ACTION: compile – Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.989 seconds messages: command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/TestLibrary.java /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/RMID.java /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/../../../../../testlibrary/ActivationLibrary.java reason: .class file out of date or does not exist elapsed time (seconds): 0.989 STDOUT: STDERR: Note: Some input files use unchecked or unsafe operations. Note: Recompile with -Xlint:unchecked for details. ACTION: build – Passed. Build successful REASON: User specified action: run build ActivateMe TIME: 0.535 seconds messages: command: build ActivateMe reason: User specified action: run build ActivateMe elapsed time (seconds): 0.535 ACTION: compile – Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.535 seconds messages: command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/ActivateMe.java reason: .class file out of date or does not exist elapsed time (seconds): 0.535 STDOUT: STDERR: ACTION: build – Passed. Build successful REASON: User specified action: run build InactiveGroup TIME: 0.64 seconds messages: command: build InactiveGroup reason: User specified action: run build InactiveGroup elapsed time (seconds): 0.64 ACTION: compile – Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.64 seconds messages: command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java reason: .class file out of date or does not exist elapsed time (seconds): 0.64 STDOUT: STDERR: ACTION: build – Passed. Build successful REASON: User specified action: run build InactiveGroup_Stub TIME: 0.589 seconds messages: command: build InactiveGroup_Stub reason: User specified action: run build InactiveGroup_Stub elapsed time (seconds): 0.589 ACTION: compile – Passed. Compilation successful REASON: .class file out of date or does not exist TIME: 0.588 seconds messages: command: compile /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/InactiveGroup_Stub.java reason: .class file out of date or does not exist elapsed time (seconds): 0.588 STDOUT: STDERR: ACTION: build – Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build InactiveGroup reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: main – Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds REASON: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup TIME: 5.726 seconds messages: command: main -Dtest.rmi.exportType=defaultInactiveGroup reason: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup elapsed time (seconds): 5.726 STDOUT: Regression test for bug 4116082 STDERR: exportType: default HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jtsk/trunk/lib-dl TEST FAILED: Test failed with: oops java.io.IOException: oops at HTTPD.<init>(HTTPD.java:111) at HTTPD.<init>(HTTPD.java:71) at RMID.start(RMID.java:184) at RMID.start(RMID.java:171) at InactiveGroup.main(InactiveGroup.java:107) 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:585) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.ClassNotFoundException: com.sun.jini.tool.ClassServer 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:306) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:242) at HTTPD$Daemon$1.run(HTTPD.java:169) at java.security.AccessController.doPrivileged(Native Method) at HTTPD$Daemon.create(HTTPD.java:163) 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:585) at HTTPD.<init>(HTTPD.java:94) ... 10 more ACTIVATION_LIBRARY: tried to shutdown when rmid was not running TEST FAILED: rmid not destroyed in: 60000 milliseconds TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds at TestLibrary.bomb(TestLibrary.java:92) at TestLibrary.bomb(TestLibrary.java:95) at ActivationLibrary.rmidCleanup(ActivationLibrary.java:195) at InactiveGroup.main(InactiveGroup.java:188) 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:585) at com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:595) JavaTest Message: Test threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds TEST RESULT: Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds -------------------------------------------------- Test results: failed: 1 Report written to JTreport/html/report.html Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork Error: Some tests failed or other problems occurred. Contents of jre/lib/ext: -------------------------------- jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ ls -al /usr/lib/jvm/java-1.5.0-sun/jre/lib/ext totaal 2408 drwxr-xr-x 2 root root 4096 2009-10-04 11:53 . drwxr-xr-x 18 root root 4096 2009-10-01 23:53 .. rw-r r - 1 root root 8215 2009-05-04 12:01 dnsns.jar rw-r r - 1 root root 246722 2009-10-04 11:10 jsk-lib.jar rw-r r - 1 root root 796635 2009-10-04 11:10 jsk-platform.jar rw-r r - 1 root root 24691 2009-10-04 11:10 jsk-policy.jar rw-r r - 1 root root 3939 2009-10-04 11:12 jsk-resources.jar rw-r r - 1 root root 810816 2009-07-15 08:54 localedata.jar rw-r r - 1 root root 2257 2009-10-04 11:10 phoenix-init.jar rw-r r - 1 root root 158419 2009-05-04 11:53 sunjce_provider.jar rw-r r - 1 root root 175949 2009-05-04 11:53 sunpkcs11.jar If I copy tools.jar into jre/lib/ext, the test passes fine: jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-1.5.0-sun net/jini/activation/Activatable/inactiveGroup Directory"JTreport" not found: creating Directory "JTwork" not found: creating Directory "JTwork/scratch" not found: creating Test results: passed: 1 Report written to JTreport/html/report.html Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork Any suggestions? Thanks Jonathan
          Hide
          Peter Firmstone added a comment -

          Have you tried setting up the codebase http server manually by running the command shown in your output above, you can test if it's working in your browser?

          Show
          Peter Firmstone added a comment - Have you tried setting up the codebase http server manually by running the command shown in your output above, you can test if it's working in your browser?
          Hide
          Peter Firmstone added a comment -

          I had used a different command syntax but tried it your way & it worked

          jtreg -verbose:all,nopass -jdk:/usr/jdk/jdk1.5.0_15 -Djsk.home=/opt/src/river/trunk/ -dir:/opt/src/river/trunk/qa/jtreg/ net/jini/activation/Activatable/inactiveGroup
          Test results: passed: 1
          Report written to JTreport/html/report.html
          Results written to /opt/src/river/trunk/qa/jtreg/JTwork

          From your output it looks like rmid is failing when it can't access phoenix.jar

          Can you add this to your jtreg command and send in the output:

          -Djava.security.debug=access,failure

          Show
          Peter Firmstone added a comment - I had used a different command syntax but tried it your way & it worked jtreg -verbose:all,nopass -jdk:/usr/jdk/jdk1.5.0_15 -Djsk.home=/opt/src/river/trunk/ -dir:/opt/src/river/trunk/qa/jtreg/ net/jini/activation/Activatable/inactiveGroup Test results: passed: 1 Report written to JTreport/html/report.html Results written to /opt/src/river/trunk/qa/jtreg/JTwork From your output it looks like rmid is failing when it can't access phoenix.jar Can you add this to your jtreg command and send in the output: -Djava.security.debug=access,failure
          Hide
          Jonathan Costers added a comment - - edited

          Here is a specific example:

          Command used:
          ----------------------
          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-6-sun net/jini/activation/Activatable/inactiveGroup

          test.props:
          --------------
          jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ cat test.props
          jsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk

          contents of jre/lib/ext:
          ----------------------------
          jonathan@calisto:~$ ls -al /usr/lib/jvm/java-6-sun/jre/lib/ext
          totaal 2588
          drwxr-xr-x 2 root root 4096 2009-10-01 23:42 .
          drwxr-xr-x 18 root root 4096 2009-08-29 16:10 ..
          rw-rr- 1 root root 246722 2009-10-01 23:38 jsk-lib.jar
          rw-rr- 1 root root 796635 2009-10-01 23:38 jsk-platform.jar
          rw-rr- 1 root root 24691 2009-10-01 23:38 jsk-policy.jar
          rw-rr- 1 root root 3939 2009-10-01 23:38 jsk-resources.jar
          rw-rr- 1 root root 841667 2009-08-29 00:07 localedata.jar
          rw-rr- 1 root root 429 2009-07-31 15:40 meta-index
          rw-rr- 1 root root 2257 2009-10-01 23:38 phoenix-init.jar
          rw-rr- 1 root root 170239 2009-07-31 15:21 sunjce_provider.jar
          rw-rr- 1 root root 231542 2009-07-31 15:28 sunpkcs11.jar
          rw-rr- 1 root root 188120 2009-10-01 23:40 tools.jar

          If I understand correctly, this is the way these tests used to be run at Sun?
          However, the activation tests fail for me.

          Result:
          --------------------------------------------------
          TEST: net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java
          JDK under test: (/usr/lib/jvm/java-6-sun)
          java version "1.6.0_16"
          Java(TM) SE Runtime Environment (build 1.6.0_16-b01)
          Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode)

          ACTION: build – Passed. All files up to date
          REASON: User specified action: run build TestLibrary RMID ActivationLibrary
          TIME: 0.0010 seconds
          messages:
          command: build TestLibrary RMID ActivationLibrary
          reason: User specified action: run build TestLibrary RMID ActivationLibrary
          elapsed time (seconds): 0.0010

          ACTION: build – Passed. All files up to date
          REASON: User specified action: run build ActivateMe
          TIME: 0.0 seconds
          messages:
          command: build ActivateMe
          reason: User specified action: run build ActivateMe
          elapsed time (seconds): 0.0

          ACTION: build – Passed. All files up to date
          REASON: User specified action: run build InactiveGroup
          TIME: 0.0 seconds
          messages:
          command: build InactiveGroup
          reason: User specified action: run build InactiveGroup
          elapsed time (seconds): 0.0

          ACTION: build – Passed. All files up to date
          REASON: User specified action: run build InactiveGroup_Stub
          TIME: 0.0 seconds
          messages:
          command: build InactiveGroup_Stub
          reason: User specified action: run build InactiveGroup_Stub
          elapsed time (seconds): 0.0

          ACTION: build – Passed. All files up to date
          REASON: Named class compiled on demand
          TIME: 0.0 seconds
          messages:
          command: build InactiveGroup
          reason: Named class compiled on demand
          elapsed time (seconds): 0.0

          ACTION: main – Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          REASON: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup
          TIME: 23.631 seconds
          messages:
          command: main -Dtest.rmi.exportType=defaultInactiveGroup
          reason: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup
          elapsed time (seconds): 23.631
          STDOUT:

          Regression test for bug 4116082

          STDERR:
          exportType: default
          HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib-dl
          RMID: starting rmid...
          JAVAVM: command = /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java -Djava.security.policy=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.security.policy -Djava.rmi.server.codebase="http://127.0.0.1:8081/phoenix-dl.jar http://127.0.0.1:8081/jsk-dl.jar" -Dtest.src=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup -Dtest.classes=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/inactiveGroup -Djsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk -jar /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.config

          JavaVM: parsed command: [/usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java, -Djava.security.policy=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.security.policy, -Djava.rmi.server.codebase=http://127.0.0.1:8081/phoenix-dl.jar http://127.0.0.1:8081/jsk-dl.jar, -Dtest.src=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup, -Dtest.classes=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/inactiveGroup, -Djsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk, -jar, /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar, /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.config]
          null: Unable to access jarfile /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar
          2-okt-2009 1:29:39 com.sun.jini.tool.ClassServer run
          INFO: ClassServer started [[/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib-dl/], port 8081]
          JAVAVM: finished starting vm.
          TEST FAILED: start rmid failed... giving up
          TEST FAILED:
          Test failed with: TEST FAILED: start rmid failed... giving up
          TestFailedException: TEST FAILED: start rmid failed... giving up
          at TestLibrary.bomb(TestLibrary.java:92)
          at RMID.start(RMID.java:209)
          at RMID.start(RMID.java:171)
          at InactiveGroup.main(InactiveGroup.java:107)
          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 com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
          at java.lang.Thread.run(Thread.java:619)
          ACTIVATION_LIBRARY: tried to shutdown when rmid was not running
          TEST FAILED: rmid not destroyed in: 60000 milliseconds
          TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          at TestLibrary.bomb(TestLibrary.java:92)
          at TestLibrary.bomb(TestLibrary.java:95)
          at ActivationLibrary.rmidCleanup(ActivationLibrary.java:195)
          at InactiveGroup.main(InactiveGroup.java:188)
          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 com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94)
          at java.lang.Thread.run(Thread.java:619)

          JavaTest Message: Test threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          JavaTest Message: shutting down test

          STATUS:Failed.`main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds

          TEST RESULT: Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds
          --------------------------------------------------
          Test results: failed: 1
          Report written to JTreport/html/report.html
          Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork
          Error: Some tests failed or other problems occurred.

          Notice the "null: Unable to access jarfile /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar" in above output ..

          The file is definitely there, fresh out of a clean build:
          jonathan@calisto:~$ ls -al Documenten/NetBeansProjects/River/jtsk/trunk/lib/phoenix.jar
          rw-rr- 1 jonathan jonathan 70451 2009-10-02 00:51 Documenten/NetBeansProjects/River/jtsk/trunk/lib/phoenix.jar

          Show
          Jonathan Costers added a comment - - edited Here is a specific example: Command used: ---------------------- jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ /home/jonathan/jtreg/linux/bin/jtreg -verbose:all,nopass -Djsk.home=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk -dir:/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg -jdk:/usr/lib/jvm/java-6-sun net/jini/activation/Activatable/inactiveGroup test.props: -------------- jonathan@calisto:~/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg$ cat test.props jsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk contents of jre/lib/ext: ---------------------------- jonathan@calisto:~$ ls -al /usr/lib/jvm/java-6-sun/jre/lib/ext totaal 2588 drwxr-xr-x 2 root root 4096 2009-10-01 23:42 . drwxr-xr-x 18 root root 4096 2009-08-29 16:10 .. rw-r r - 1 root root 246722 2009-10-01 23:38 jsk-lib.jar rw-r r - 1 root root 796635 2009-10-01 23:38 jsk-platform.jar rw-r r - 1 root root 24691 2009-10-01 23:38 jsk-policy.jar rw-r r - 1 root root 3939 2009-10-01 23:38 jsk-resources.jar rw-r r - 1 root root 841667 2009-08-29 00:07 localedata.jar rw-r r - 1 root root 429 2009-07-31 15:40 meta-index rw-r r - 1 root root 2257 2009-10-01 23:38 phoenix-init.jar rw-r r - 1 root root 170239 2009-07-31 15:21 sunjce_provider.jar rw-r r - 1 root root 231542 2009-07-31 15:28 sunpkcs11.jar rw-r r - 1 root root 188120 2009-10-01 23:40 tools.jar If I understand correctly, this is the way these tests used to be run at Sun? However, the activation tests fail for me. Result: -------------------------------------------------- TEST: net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java JDK under test: (/usr/lib/jvm/java-6-sun) java version "1.6.0_16" Java(TM) SE Runtime Environment (build 1.6.0_16-b01) Java HotSpot(TM) Server VM (build 14.2-b01, mixed mode) ACTION: build – Passed. All files up to date REASON: User specified action: run build TestLibrary RMID ActivationLibrary TIME: 0.0010 seconds messages: command: build TestLibrary RMID ActivationLibrary reason: User specified action: run build TestLibrary RMID ActivationLibrary elapsed time (seconds): 0.0010 ACTION: build – Passed. All files up to date REASON: User specified action: run build ActivateMe TIME: 0.0 seconds messages: command: build ActivateMe reason: User specified action: run build ActivateMe elapsed time (seconds): 0.0 ACTION: build – Passed. All files up to date REASON: User specified action: run build InactiveGroup TIME: 0.0 seconds messages: command: build InactiveGroup reason: User specified action: run build InactiveGroup elapsed time (seconds): 0.0 ACTION: build – Passed. All files up to date REASON: User specified action: run build InactiveGroup_Stub TIME: 0.0 seconds messages: command: build InactiveGroup_Stub reason: User specified action: run build InactiveGroup_Stub elapsed time (seconds): 0.0 ACTION: build – Passed. All files up to date REASON: Named class compiled on demand TIME: 0.0 seconds messages: command: build InactiveGroup reason: Named class compiled on demand elapsed time (seconds): 0.0 ACTION: main – Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds REASON: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup TIME: 23.631 seconds messages: command: main -Dtest.rmi.exportType=defaultInactiveGroup reason: User specified action: run main/othervm/policy=security.policy/timeout=240 -Dtest.rmi.exportType=default InactiveGroup elapsed time (seconds): 23.631 STDOUT: Regression test for bug 4116082 STDERR: exportType: default HTTPD: using /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/tools.jar on port 8081 serving /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib-dl RMID: starting rmid... JAVAVM: command = /usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java -Djava.security.policy=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.security.policy -Djava.rmi.server.codebase="http://127.0.0.1:8081/phoenix-dl.jar http://127.0.0.1:8081/jsk-dl.jar " -Dtest.src=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup -Dtest.classes=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/inactiveGroup -Djsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk -jar /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.config JavaVM: parsed command: [/usr/lib/jvm/java-6-sun-1.6.0.16/jre/bin/java, -Djava.security.policy=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.security.policy, -Djava.rmi.server.codebase=http://127.0.0.1:8081/phoenix-dl.jar http://127.0.0.1:8081/jsk-dl.jar, -Dtest.src=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup, -Dtest.classes=/home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/inactiveGroup, -Djsk.home=/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk, -jar, /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar, /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/net/jini/activation/Activatable/inactiveGroup/rmid.config] null: Unable to access jarfile /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar 2-okt-2009 1:29:39 com.sun.jini.tool.ClassServer run INFO: ClassServer started [ [/home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib-dl/] , port 8081] JAVAVM: finished starting vm. TEST FAILED: start rmid failed... giving up TEST FAILED: Test failed with: TEST FAILED: start rmid failed... giving up TestFailedException: TEST FAILED: start rmid failed... giving up at TestLibrary.bomb(TestLibrary.java:92) at RMID.start(RMID.java:209) at RMID.start(RMID.java:171) at InactiveGroup.main(InactiveGroup.java:107) 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 com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:619) ACTIVATION_LIBRARY: tried to shutdown when rmid was not running TEST FAILED: rmid not destroyed in: 60000 milliseconds TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds at TestLibrary.bomb(TestLibrary.java:92) at TestLibrary.bomb(TestLibrary.java:95) at ActivationLibrary.rmidCleanup(ActivationLibrary.java:195) at InactiveGroup.main(InactiveGroup.java:188) 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 com.sun.javatest.regtest.MainWrapper$MainThread.run(MainWrapper.java:94) at java.lang.Thread.run(Thread.java:619) JavaTest Message: Test threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds TEST RESULT: Failed. Execution failed: `main' threw exception: TestFailedException: TEST FAILED: rmid not destroyed in: 60000 milliseconds -------------------------------------------------- Test results: failed: 1 Report written to JTreport/html/report.html Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork Error: Some tests failed or other problems occurred. Notice the "null: Unable to access jarfile /home/jonathan/Documenten/NetbeansProjects/River/jstk/trunk/lib/phoenix.jar" in above output .. The file is definitely there, fresh out of a clean build: jonathan@calisto:~$ ls -al Documenten/NetBeansProjects/River/jtsk/trunk/lib/phoenix.jar rw-r r - 1 jonathan jonathan 70451 2009-10-02 00:51 Documenten/NetBeansProjects/River/jtsk/trunk/lib/phoenix.jar
          Hide
          Jonathan Costers added a comment - - edited

          Results of first jtreg run from Ant build process are attached above

          Show
          Jonathan Costers added a comment - - edited Results of first jtreg run from Ant build process are attached above
          Hide
          Jonathan Costers added a comment -

          I have run all jtreg tests from Ant and this is the result:

          Test results: passed: 106; failed: 32
          Report written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTreport/html/report.html
          Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork
          Error: Some tests failed or other problems occurred.
          /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/build.xml:147: Error: Some tests failed or other problems occurred.
          BUILD FAILED (total time: 19 minutes 26 seconds)

          A lot of the failures are of course explained by comments made above.
          Looking into ways to solve.

          Show
          Jonathan Costers added a comment - I have run all jtreg tests from Ant and this is the result: Test results: passed: 106; failed: 32 Report written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTreport/html/report.html Results written to /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/jtreg/JTwork Error: Some tests failed or other problems occurred. /home/jonathan/Documenten/NetBeansProjects/River/jtsk/trunk/qa/build.xml:147: Error: Some tests failed or other problems occurred. BUILD FAILED (total time: 19 minutes 26 seconds) A lot of the failures are of course explained by comments made above. Looking into ways to solve.
          Hide
          Peter Firmstone added a comment -

          jtreg test TODO list for AR3 release:

          • Debug failed TestParser test.
          • Implement Kerberos KDC server at river.zones.apache.org
          • Confirm Kerberos Tests pass on JDK1.5
          • Find solution to missing jiniproxy
          • Find alternative to moving Libraries into jre/lib/ext directory
          • Refactor test directory naming scheme in river/trunk/
          • Document how to run jtreg tests from the command line and
            incorporate into a README.txt file.
          • Write Ant script to run jtreg tests.
          • Find replacement or replicate required functionality of
            sun.net.spi.nameservice API
          • kinit - replacement required, prefer platform independent java
            implementation, I'm going to ask Apache Harmony, they have this on
            their TODO list.

          JT Harness : Tests that failed

          Tests are grouped by their final status message.

          Execution failed: `main' threw exception:
          java.rmi.UnknownHostException: unknown host in
          BasicObjectEndpoint[1a464871-e4db-467b-b54e-042acf40a044,HttpEndpoint[10.1.1.2:50914]];
          nested exception is: java.net.UnknownHostException: jiniproxy

          • net/jini/jeri/http/echo/EchoImpl.java
            <cid:part1.06040000.07060309@zeus.net.au> : Echo implementation
            for testing basic HTTP endpoint functionality.

          Execution failed: exit code 1

          • net/jini/config/ConfigurationFile/TestParser/TestParser.java
            <cid:part2.02050807.05030100@zeus.net.au> : Tests parsing
            configuration files.
          • net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh
            <cid:part3.04070208.02080208@zeus.net.au> : Different
            ServerEndPoints must allow export on same ListenEndPoint
          • net/jini/jeri/transport/multihomed/runMultihome.sh
            <cid:part4.02080907.04040205@zeus.net.au> : Test the
            KerberosEndpoint for multihome support

          Execution failed: exit code 255

          • net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh
            <cid:part5.08040904.05070800@zeus.net.au> : Test the
            KerberosEndpoint and KerberosServerEndpoint classes.
          • net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh
            <cid:part6.09090700.09040005@zeus.net.au> : Tests the end to end
            performance of Kerberos provider.
          Show
          Peter Firmstone added a comment - jtreg test TODO list for AR3 release: Debug failed TestParser test. Implement Kerberos KDC server at river.zones.apache.org Confirm Kerberos Tests pass on JDK1.5 Find solution to missing jiniproxy Find alternative to moving Libraries into jre/lib/ext directory Refactor test directory naming scheme in river/trunk/ Document how to run jtreg tests from the command line and incorporate into a README.txt file. Write Ant script to run jtreg tests. Find replacement or replicate required functionality of sun.net.spi.nameservice API kinit - replacement required, prefer platform independent java implementation, I'm going to ask Apache Harmony, they have this on their TODO list. JT Harness : Tests that failed Tests are grouped by their final status message. Execution failed: `main' threw exception: java.rmi.UnknownHostException: unknown host in BasicObjectEndpoint[1a464871-e4db-467b-b54e-042acf40a044,HttpEndpoint [10.1.1.2:50914] ]; nested exception is: java.net.UnknownHostException: jiniproxy net/jini/jeri/http/echo/EchoImpl.java <cid:part1.06040000.07060309@zeus.net.au> : Echo implementation for testing basic HTTP endpoint functionality. Execution failed: exit code 1 net/jini/config/ConfigurationFile/TestParser/TestParser.java <cid:part2.02050807.05030100@zeus.net.au> : Tests parsing configuration files. net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh <cid:part3.04070208.02080208@zeus.net.au> : Different ServerEndPoints must allow export on same ListenEndPoint net/jini/jeri/transport/multihomed/runMultihome.sh <cid:part4.02080907.04040205@zeus.net.au> : Test the KerberosEndpoint for multihome support Execution failed: exit code 255 net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh <cid:part5.08040904.05070800@zeus.net.au> : Test the KerberosEndpoint and KerberosServerEndpoint classes. net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh <cid:part6.09090700.09040005@zeus.net.au> : Tests the end to end performance of Kerberos provider.
          Hide
          Peter Firmstone added a comment -

          Good news, got to the bottom of the problem of the failing tests:

          Well it's a case of not following Peter Jones instructions explicitly, I placed links to the following files in the jre/lib/ext directory to their native location in river/trunk, see further below. While studying the output I noticed that the jar's were still being accessed from their location in river/trunk where they're placed during the build process, Peter's comment "put" clicked, I moved the files to the jre/lib/ext directory and now only 8 tests fail as we've previously discussed (I haven't re run all tests yet though, only those that failed).

          jsk-lib.jar
          jsk-platform.jar
          jsk-policy.jar
          jsk-resources.jar
          phoenix-init.jar

          To quote Peter Jones:

          "The JVM's security mechanisms canonicalize file paths, like the code sources of JAR files, in order to defend against the thwarting of security policy via symbolic links."

          And:

          "The (primary) difficulty is getting the security policies to grant AllPermission to those JARs (but not all code, in particular not to the test code) without that location being hard-coded. Security policy files support system property expansion, so perhaps the location could be specified with a system property supplied to jtreg (along with a class path as you had been doing before), although this property might also need to be explicitly propagated to child processes of the tests, like for the tests that start phoenix (rmid).

          I'm not sure if there are any other assumptions made by those tests that those JAR files are in the extensions directory, or more to the point, that their classes are defined by the extensions class loader instead of the system class loader-- the only case I can think of is if the dynamic security policy provider is set via a system property. I doubt that there are much if anything issues like that, though-- easiest to discover by trying."

          After further test runs, on JDK 1.5 only 6 tests fail they are:

          JT Harness : Tests that failed
          Tests are grouped by their final status message.
          Execution failed: `main' threw exception: java.rmi.UnknownHostException: unknown host in BasicObjectEndpoint[195c508a-04c6-4182-b249-c17fd7fb59e2,HttpEndpoint[10.1.1.2:52884]]; nested exception is: java.net.UnknownHostException: jiniproxy

          • net/jini/jeri/http/echo/EchoImpl.java : Echo implementation for testing basic HTTP endpoint functionality.

          Execution failed: exit code 1

          • net/jini/config/ConfigurationFile/TestParser/TestParser.java : Tests parsing configuration files.
          • net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh : Different ServerEndPoints must allow export on same ListenEndPoint
          • net/jini/jeri/transport/multihomed/runMultihome.sh : Test the KerberosEndpoint for multihome support

          Execution failed: exit code 255

          • net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh : Test the KerberosEndpoint and KerberosServerEndpoint classes.
          • net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh : Tests the end to end performance of Kerberos provider.

          Report generated on 19/06/2009 13:40:54
          Using JT Harness 4.1.3a; built on 25 April 2008 0:00:00 with Java(TM) 2 SDK, Version 1.5.0

          Show
          Peter Firmstone added a comment - Good news, got to the bottom of the problem of the failing tests: Well it's a case of not following Peter Jones instructions explicitly, I placed links to the following files in the jre/lib/ext directory to their native location in river/trunk, see further below. While studying the output I noticed that the jar's were still being accessed from their location in river/trunk where they're placed during the build process, Peter's comment "put" clicked, I moved the files to the jre/lib/ext directory and now only 8 tests fail as we've previously discussed (I haven't re run all tests yet though, only those that failed). jsk-lib.jar jsk-platform.jar jsk-policy.jar jsk-resources.jar phoenix-init.jar To quote Peter Jones: "The JVM's security mechanisms canonicalize file paths, like the code sources of JAR files, in order to defend against the thwarting of security policy via symbolic links." And: "The (primary) difficulty is getting the security policies to grant AllPermission to those JARs (but not all code, in particular not to the test code) without that location being hard-coded. Security policy files support system property expansion, so perhaps the location could be specified with a system property supplied to jtreg (along with a class path as you had been doing before), although this property might also need to be explicitly propagated to child processes of the tests, like for the tests that start phoenix (rmid). I'm not sure if there are any other assumptions made by those tests that those JAR files are in the extensions directory, or more to the point, that their classes are defined by the extensions class loader instead of the system class loader-- the only case I can think of is if the dynamic security policy provider is set via a system property. I doubt that there are much if anything issues like that, though-- easiest to discover by trying." After further test runs, on JDK 1.5 only 6 tests fail they are: JT Harness : Tests that failed Tests are grouped by their final status message. Execution failed: `main' threw exception: java.rmi.UnknownHostException: unknown host in BasicObjectEndpoint[195c508a-04c6-4182-b249-c17fd7fb59e2,HttpEndpoint [10.1.1.2:52884] ]; nested exception is: java.net.UnknownHostException: jiniproxy net/jini/jeri/http/echo/EchoImpl.java : Echo implementation for testing basic HTTP endpoint functionality. Execution failed: exit code 1 net/jini/config/ConfigurationFile/TestParser/TestParser.java : Tests parsing configuration files. net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh : Different ServerEndPoints must allow export on same ListenEndPoint net/jini/jeri/transport/multihomed/runMultihome.sh : Test the KerberosEndpoint for multihome support Execution failed: exit code 255 net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh : Test the KerberosEndpoint and KerberosServerEndpoint classes. net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh : Tests the end to end performance of Kerberos provider. Report generated on 19/06/2009 13:40:54 Using JT Harness 4.1.3a; built on 25 April 2008 0:00:00 with Java(TM) 2 SDK, Version 1.5.0
          Hide
          Peter Jones added a comment -

          It appears that some of the remaining problems Peter Firmstone was having with these tests were because he was using the -cpa option to jtreg to include the "classes" tree from the River build in the tests' class paths. While this might have seemed like a perfectly appropriate thing to do, it wasn't the way that these tests were run at Sun, and it happens to interfere with a convoluted class loader mechanism used by the testlibrary/HTTPD.java utility (which starts a class server and is used by many of the tests that were failing for him) to grant permissions to the build's tools.jar without requiring the tests' security policy files to have any hard-coded paths to River build artifacts.

          In summary, as they are, these tests are not expected to be run with any -cpa option passed to jtreg.

          Show
          Peter Jones added a comment - It appears that some of the remaining problems Peter Firmstone was having with these tests were because he was using the -cpa option to jtreg to include the "classes" tree from the River build in the tests' class paths. While this might have seemed like a perfectly appropriate thing to do, it wasn't the way that these tests were run at Sun, and it happens to interfere with a convoluted class loader mechanism used by the testlibrary/HTTPD.java utility (which starts a class server and is used by many of the tests that were failing for him) to grant permissions to the build's tools.jar without requiring the tests' security policy files to have any hard-coded paths to River build artifacts. In summary, as they are, these tests are not expected to be run with any -cpa option passed to jtreg.
          Hide
          Peter Firmstone added a comment -

          Has anyone apart from myself run the jtreg tests on Solaris 10 sparc? I'm wondering how to move forward on this issue?

          I'm considering working through all 34 tests that failed on my system and add the required permissions. then submitting a patch.

          Show
          Peter Firmstone added a comment - Has anyone apart from myself run the jtreg tests on Solaris 10 sparc? I'm wondering how to move forward on this issue? I'm considering working through all 34 tests that failed on my system and add the required permissions. then submitting a patch.
          Hide
          Peter Firmstone added a comment -

          Focusing on one test:

          TEST: net/jini/activation/Activatable/activateExceptionTest/ActivateExceptionTest.java.

          I made the changes below to the security.policy file, specific to this test, the test then passed.

          Does anyone have any idea why my system (Solaris 10 sparc) requires the additional permissions to be explicitly defined? Note that the system wide security policy is ignored, jtreg uses the test specific security.policy.

          /*

          • security policy used by the test process
            */

          grant codeBase "file:$

          {java.home}/lib/ext/*" { permission java.security.AllPermission; };

          grant {
          // standard test activation permissions
          permission java.io.FilePermission "..${/}..${/}test.props", "read";

          // for HTTPD
          permission java.lang.RuntimePermission "createClassLoader";
          permission java.io.FilePermission "${/}opt${/}src${/}river${/}trunk${/}lib-dl${/}*", "read"; //Added this line I couldn't use jsk.home as it isn't defined here

          // test needs to cleanup rmid's log.
          permission java.io.FilePermission ".${/}log", "read,write,delete";
          permission java.io.FilePermission ".${/}log${/}-", "read,write,delete";

          // test needs to use java to exec an rmid
          permission java.io.FilePermission "${java.home}

          $

          {/}bin${/}

          java", "execute";

          // test rmid uses these properties to propagate security values to rmid
          permission java.util.PropertyPermission "java.security.policy", "read";
          permission java.util.PropertyPermission "java.security.manager", "read";

          // used by TestLibrary to determine test environment
          permission java.util.PropertyPermission "test.classes", "read";
          permission java.util.PropertyPermission "test.src", "read";
          permission java.util.PropertyPermission "user.dir", "read";
          permission java.util.PropertyPermission "java.home", "read";

          permission java.util.PropertyPermission "test.rmi.exportType", "read";

          // outbound calls
          permission java.net.SocketPermission "*:1024-", "connect,listen,accept,resolve"; //Added listen,accept,resolve

          // allow getting impl's class loader for export
          permission java.lang.RuntimePermission "getClassLoader";
          };

          Show
          Peter Firmstone added a comment - Focusing on one test: TEST: net/jini/activation/Activatable/activateExceptionTest/ActivateExceptionTest.java. I made the changes below to the security.policy file, specific to this test, the test then passed. Does anyone have any idea why my system (Solaris 10 sparc) requires the additional permissions to be explicitly defined? Note that the system wide security policy is ignored, jtreg uses the test specific security.policy. /* security policy used by the test process */ grant codeBase "file:$ {java.home}/lib/ext/*" { permission java.security.AllPermission; }; grant { // standard test activation permissions permission java.io.FilePermission "..${/}..${/}test.props", "read"; // for HTTPD permission java.lang.RuntimePermission "createClassLoader"; permission java.io.FilePermission "${/}opt${/}src${/}river${/}trunk${/}lib-dl${/}*", "read"; //Added this line I couldn't use jsk.home as it isn't defined here // test needs to cleanup rmid's log. permission java.io.FilePermission ".${/}log", "read,write,delete"; permission java.io.FilePermission ".${/}log${/}-", "read,write,delete"; // test needs to use java to exec an rmid permission java.io.FilePermission "${java.home} $ {/}bin${/} java", "execute"; // test rmid uses these properties to propagate security values to rmid permission java.util.PropertyPermission "java.security.policy", "read"; permission java.util.PropertyPermission "java.security.manager", "read"; // used by TestLibrary to determine test environment permission java.util.PropertyPermission "test.classes", "read"; permission java.util.PropertyPermission "test.src", "read"; permission java.util.PropertyPermission "user.dir", "read"; permission java.util.PropertyPermission "java.home", "read"; permission java.util.PropertyPermission "test.rmi.exportType", "read"; // outbound calls permission java.net.SocketPermission "*:1024-", "connect,listen,accept,resolve"; //Added listen,accept,resolve // allow getting impl's class loader for export permission java.lang.RuntimePermission "getClassLoader"; };
          Hide
          Peter Jones added a comment -

          It has been brought to my attention that I should mention another
          configuration step that many of the River jtreg tests assume: that
          there is a properties file located at "../../test.props" relative to
          the working directory of the tests, which with the default directories
          produced by JavaTest means at the same level as the "JTreport" and
          "JTwork" directories. The properties in this file are only used for a
          few things, and most of them are optional, but one of them is not
          optional for several of the tests: they expect a property named
          "jsk.home" to be an absolute path to the root of the starter kit build,
          i.e. the directory containing the "lib", "lib-dl", and "lib-ext"
          directories. For example, in my recent runs, I was using a
          "test.props" file with this one line:

          jsk.home = /files/ws/river/jtreg-help/jtsk

          That property is used by all of the activation-related tests that
          start an activation daemon, as well as some of the tests that start a
          class server.

          Show
          Peter Jones added a comment - It has been brought to my attention that I should mention another configuration step that many of the River jtreg tests assume: that there is a properties file located at "../../test.props" relative to the working directory of the tests, which with the default directories produced by JavaTest means at the same level as the "JTreport" and "JTwork" directories. The properties in this file are only used for a few things, and most of them are optional, but one of them is not optional for several of the tests: they expect a property named "jsk.home" to be an absolute path to the root of the starter kit build, i.e. the directory containing the "lib", "lib-dl", and "lib-ext" directories. For example, in my recent runs, I was using a "test.props" file with this one line: jsk.home = /files/ws/river/jtreg-help/jtsk That property is used by all of the activation-related tests that start an activation daemon, as well as some of the tests that start a class server.
          Hide
          Peter Jones added a comment -

          > the jtreg tests exist in two source trees in the River project:
          >
          > 1. in the old qatests trunk
          >
          > 2. In the main River trunk branch under river/jtsk/trunk/qa/jtreg, that Jonathan and Tom recently moved the QA tests.

          For the results I described in my 01/May/2009 comment above, I used the jtreg tests under river/jtsk/trunk/qa/jtreg (i.e your case 2).

          Show
          Peter Jones added a comment - > the jtreg tests exist in two source trees in the River project: > > 1. in the old qatests trunk > > 2. In the main River trunk branch under river/jtsk/trunk/qa/jtreg, that Jonathan and Tom recently moved the QA tests. For the results I described in my 01/May/2009 comment above, I used the jtreg tests under river/jtsk/trunk/qa/jtreg (i.e your case 2).
          Hide
          Peter Firmstone added a comment -

          the jtreg tests exist in two source trees in the River project:

          1. in the old qatests trunk

          2. In the main River trunk branch under river/jtsk/trunk/qa/jtreg, that Jonathan and Tom recently moved the QA tests.

          The maximum nuber of jtreg tests that pass on my system 104, the number that fail: 34

          The failed tests over and above those explained by Peter Jones appear to be related to the http server ClassServer

          I have tested this on my system with JDK 1.4.2, JDK1.5 and JDK1.6 with the similar results.

          I set up a symbolic link from /vob/jive to /opt/src/river/trunk so the ClassServer can serve up the required lib jar files. When trying to download one of these files manually from ClassServer I get a 0 byte jar archive.

          In the instructions, for building the qa tests, the primary build makefile is missing

          5. BUILD - the qa tests

          > cd ~/river/qatests/trunk/source/vob
          > make clean (optional)
          > make
          > make jars

          There is another ClassServer.java source file in qatests/trunk/source/vob/tools/src/com/sun/jini/tool
          This is almost identical to that in the jtsk, they share the same namespace com.sun.jini.tool the only differences are in comments and one import statement.

          Here's a diff output of the two classfiles

          diff ClassServer.java /opt/src/River/jtsk/trunk/src/com/sun/jini/tool/ClassServer.java
          34d33
          < import java.net.URL;
          119c118
          < * % java -jar <var><b>install_dir</b></var>/lib/classserver.jar

          > * % java -jar <var><b>install_dir</b></var>/lib/classserver.jar \
          123c122
          < * is the directory where the starter kit is installed.

          > * is the directory where the Apache River release is installed.
          131,132c130,131
          < * % java -Djava.security.policy=<var><b>start_policy</b></var>
          < * -jar <var><b>install_dir</b></var>/lib/start.jar

          > * % java -Djava.security.policy=<var><b>start_policy</b></var> \
          > * -jar <var><b>install_dir</b></var>/lib/start.jar \

          Show
          Peter Firmstone added a comment - the jtreg tests exist in two source trees in the River project: 1. in the old qatests trunk 2. In the main River trunk branch under river/jtsk/trunk/qa/jtreg, that Jonathan and Tom recently moved the QA tests. The maximum nuber of jtreg tests that pass on my system 104, the number that fail: 34 The failed tests over and above those explained by Peter Jones appear to be related to the http server ClassServer I have tested this on my system with JDK 1.4.2, JDK1.5 and JDK1.6 with the similar results. I set up a symbolic link from /vob/jive to /opt/src/river/trunk so the ClassServer can serve up the required lib jar files. When trying to download one of these files manually from ClassServer I get a 0 byte jar archive. In the instructions, for building the qa tests, the primary build makefile is missing 5. BUILD - the qa tests > cd ~/river/qatests/trunk/source/vob > make clean (optional) > make > make jars There is another ClassServer.java source file in qatests/trunk/source/vob/tools/src/com/sun/jini/tool This is almost identical to that in the jtsk, they share the same namespace com.sun.jini.tool the only differences are in comments and one import statement. Here's a diff output of the two classfiles diff ClassServer.java /opt/src/River/jtsk/trunk/src/com/sun/jini/tool/ClassServer.java 34d33 < import java.net.URL; 119c118 < * % java -jar <var><b>install_dir</b></var>/lib/classserver.jar — > * % java -jar <var><b>install_dir</b></var>/lib/classserver.jar \ 123c122 < * is the directory where the starter kit is installed. — > * is the directory where the Apache River release is installed. 131,132c130,131 < * % java -Djava.security.policy=<var><b>start_policy</b></var> < * -jar <var><b>install_dir</b></var>/lib/start.jar — > * % java -Djava.security.policy=<var><b>start_policy</b></var> \ > * -jar <var><b>install_dir</b></var>/lib/start.jar \
          Hide
          Peter Jones added a comment -

          I'm not sure of the exact cause of the permission failures Peter
          Firmstone is seeing with the River jtreg tests, but for the record,
          many of these tests have security policy files that expect that the
          following JAR files from the River build:

          lib/jsk-platform.jar
          lib/jsk-resources.jar
          lib/jsk-lib.jar
          lib/phoenix-init.jar
          lib-ext/jsk-policy.jar

          are in the extensions directory ([jre/]lib/ext) of the JRE used to
          execute the tests. Also note that when jtreg sets a security policy
          for test execution-- such as due to the /policy action option-- it does
          so with the behavior of prefixing the java.security.policy system
          property with "=", meaning that the JRE's system and user security
          policies are ignored. See the doc for the /policy option here:
          http://openjdk.java.net/jtreg/tag-spec.txt
          And the doc for the java.security.policy system property here:
          http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#DefaultLocs
          The security policy files for the River jtreg tests include a grant of
          AllPermission to the JRE's extentions directory, similar to the defualt
          JRE security policy, so that jsk-platform.jar, etc., will have the
          permissions they need.

          For comparison, I just ran the River jtreg suite myself against a fresh
          build of the River trunk, using JDK 6u11, with the following results:

          Test results: passed: 130; failed: 8

          Here are some comments about the 8 tests that failed for me:

          FAILED: net/jini/config/ConfigurationFile/TestParser/TestParser.java

          This is the only failure that I don't understand at this point. (This
          test is a script-driven suite of unit tests of the ConfigurationFile
          parser.)

          FAILED: net/jini/jeri/http/echo/EchoImpl.java

          This test failed for me because it couldn't resolve the host name
          "jiniproxy", where-- for one variation of the test-- it is expecting to
          find an HTTP proxy, in order to test HTTP proxy support for the
          net.jini.jeri.http transport implementation. Clearly, this was an
          assumption about the internal Sun environment which doesn't even hold
          here/there anymore.

          FAILED: net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh

          Another failed assumption of the previous internal Sun environment:
          this test is expecting to find a Kerberos KDC at the host name
          "jiniautot.east.sun.com".

          FAILED: net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh
          FAILED: net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh

          These tests failed because they attempt to invoke the JRE's "kinit"
          tool using the internal sun.security.krb5.internal.tools.Kinit API,
          from which it was available in 1.4.x and 5.0 JRE versions. The Java
          version of this tool was removed from the Solaris and Linux JREs for
          version 6 because there is a native kinit on those platforms, although
          it remains in the Windows JRE.

          Beyond this kinit problem, though, these Kerberos tests would surely
          have failed expecting to find a KDC at "jiniautot.east.sun.com" like
          the previous two.

          FAILED: net/jini/jeri/tcp/localHostExposure/LocalHostExposure.java
          FAILED: net/jini/jeri/transport/multihomed/Multihomed.java
          FAILED: net/jini/jeri/transport/multihomed/runMultihome.sh

          These tests failed during the compilation phase because of this issue
          discussed recently here:

          http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200904.mbox/%3C20090421151237.GA19950@east%3E

          That is, the dependency of certain tests (in the QA suite and the jtreg
          suite) on the JDK-internal sun.net.spi.nameservice API, which changed
          incompatibly between JDK 5.0 and JDK 6. The dependencies in the QA
          suite were modified by Brian Murphy to work with the JDK 6 version, but
          not the dependencies in the jtreg suite. It's straightforward to
          modify them to work with one version of the JDK or the other, but
          somewhat tricky to make them work with both at the same time. For
          consistency, it probably makes sense to make them work with JDK 6 at
          least.

          Show
          Peter Jones added a comment - I'm not sure of the exact cause of the permission failures Peter Firmstone is seeing with the River jtreg tests, but for the record, many of these tests have security policy files that expect that the following JAR files from the River build: lib/jsk-platform.jar lib/jsk-resources.jar lib/jsk-lib.jar lib/phoenix-init.jar lib-ext/jsk-policy.jar are in the extensions directory ( [jre/] lib/ext) of the JRE used to execute the tests. Also note that when jtreg sets a security policy for test execution-- such as due to the /policy action option-- it does so with the behavior of prefixing the java.security.policy system property with "=", meaning that the JRE's system and user security policies are ignored. See the doc for the /policy option here: http://openjdk.java.net/jtreg/tag-spec.txt And the doc for the java.security.policy system property here: http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html#DefaultLocs The security policy files for the River jtreg tests include a grant of AllPermission to the JRE's extentions directory, similar to the defualt JRE security policy, so that jsk-platform.jar, etc., will have the permissions they need. For comparison, I just ran the River jtreg suite myself against a fresh build of the River trunk, using JDK 6u11, with the following results: Test results: passed: 130; failed: 8 Here are some comments about the 8 tests that failed for me: FAILED: net/jini/config/ConfigurationFile/TestParser/TestParser.java This is the only failure that I don't understand at this point. (This test is a script-driven suite of unit tests of the ConfigurationFile parser.) FAILED: net/jini/jeri/http/echo/EchoImpl.java This test failed for me because it couldn't resolve the host name "jiniproxy", where-- for one variation of the test-- it is expecting to find an HTTP proxy, in order to test HTTP proxy support for the net.jini.jeri.http transport implementation. Clearly, this was an assumption about the internal Sun environment which doesn't even hold here/there anymore. FAILED: net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh Another failed assumption of the previous internal Sun environment: this test is expecting to find a Kerberos KDC at the host name "jiniautot.east.sun.com". FAILED: net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh FAILED: net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh These tests failed because they attempt to invoke the JRE's "kinit" tool using the internal sun.security.krb5.internal.tools.Kinit API, from which it was available in 1.4.x and 5.0 JRE versions. The Java version of this tool was removed from the Solaris and Linux JREs for version 6 because there is a native kinit on those platforms, although it remains in the Windows JRE. Beyond this kinit problem, though, these Kerberos tests would surely have failed expecting to find a KDC at "jiniautot.east.sun.com" like the previous two. FAILED: net/jini/jeri/tcp/localHostExposure/LocalHostExposure.java FAILED: net/jini/jeri/transport/multihomed/Multihomed.java FAILED: net/jini/jeri/transport/multihomed/runMultihome.sh These tests failed during the compilation phase because of this issue discussed recently here: http://mail-archives.apache.org/mod_mbox/incubator-river-dev/200904.mbox/%3C20090421151237.GA19950@east%3E That is, the dependency of certain tests (in the QA suite and the jtreg suite) on the JDK-internal sun.net.spi.nameservice API, which changed incompatibly between JDK 5.0 and JDK 6. The dependencies in the QA suite were modified by Brian Murphy to work with the JDK 6 version, but not the dependencies in the jtreg suite. It's straightforward to modify them to work with one version of the JDK or the other, but somewhat tricky to make them work with both at the same time. For consistency, it probably makes sense to make them work with JDK 6 at least.
          Hide
          Peter Firmstone added a comment -

          I'm a security permission issue running the jtreg tests. Test results: passed: 65; failed: 73

          Please all familiar with this tool, look at the attached files and reports, see if you can help solve this problem.

          I'm running:

          bash-3.00$ java -version
          java version "1.6.0_07"
          Java(TM) Platform, Standard Edition for Business (build 1.6.0_07-b06)
          Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode)

          bash-3.00$ uname -a
          SunOS bluto 5.10 Generic_137111-06 sun4u sparc SUNW,Ultra-80

          Regards & Thanks,

          Peter Firmstone.

          Just in case, here's the contents of my java.policy file /usr/jdk/latest/jre/lib/security/java.policy

          1. cat java.policy
            /* AUTOMATICALLY GENERATED ON Tue Apr 28 17:33:28 EST 2009*/
            /* DO NOT EDIT */

          grant codeBase "file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/*"

          { permission java.security.AllPermission; };

          grant codeBase "file:/usr/jdk/packages/lib/ext/*" { permission java.security.AllPermission; }

          ;

          grant

          { permission java.lang.RuntimePermission "stopThread"; permission java.net.SocketPermission "localhost:1024-", "listen"; permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read"; permission java.net.SocketPermission "localhost:8081", "listen, resolve"; }

          ;

          grant codeBase "http://localhost:8081/*"

          { permission java.security.AllPermission; };

          grant codeBase "file:/opt/src/river/trunk/*" { permission java.security.AllPermission; }

          ;

          grant codeBase "file:/usr/local/java/lib/*"

          { permission java.security.AllPermission; };

          grant codeBase "http://bluto:8081/*" { permission java.security.AllPermission; }

          ;

          Show
          Peter Firmstone added a comment - I'm a security permission issue running the jtreg tests. Test results: passed: 65; failed: 73 Please all familiar with this tool, look at the attached files and reports, see if you can help solve this problem. I'm running: bash-3.00$ java -version java version "1.6.0_07" Java(TM) Platform, Standard Edition for Business (build 1.6.0_07-b06) Java HotSpot(TM) Server VM (build 10.0-b23, mixed mode) bash-3.00$ uname -a SunOS bluto 5.10 Generic_137111-06 sun4u sparc SUNW,Ultra-80 Regards & Thanks, Peter Firmstone. Just in case, here's the contents of my java.policy file /usr/jdk/latest/jre/lib/security/java.policy cat java.policy /* AUTOMATICALLY GENERATED ON Tue Apr 28 17:33:28 EST 2009*/ /* DO NOT EDIT */ grant codeBase "file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/*" { permission java.security.AllPermission; }; grant codeBase "file:/usr/jdk/packages/lib/ext/*" { permission java.security.AllPermission; } ; grant { permission java.lang.RuntimePermission "stopThread"; permission java.net.SocketPermission "localhost:1024-", "listen"; permission java.util.PropertyPermission "java.version", "read"; permission java.util.PropertyPermission "java.vendor", "read"; permission java.util.PropertyPermission "java.vendor.url", "read"; permission java.util.PropertyPermission "java.class.version", "read"; permission java.util.PropertyPermission "os.name", "read"; permission java.util.PropertyPermission "os.version", "read"; permission java.util.PropertyPermission "os.arch", "read"; permission java.util.PropertyPermission "file.separator", "read"; permission java.util.PropertyPermission "path.separator", "read"; permission java.util.PropertyPermission "line.separator", "read"; permission java.util.PropertyPermission "java.specification.version", "read"; permission java.util.PropertyPermission "java.specification.vendor", "read"; permission java.util.PropertyPermission "java.specification.name", "read"; permission java.util.PropertyPermission "java.vm.specification.version", "read"; permission java.util.PropertyPermission "java.vm.specification.vendor", "read"; permission java.util.PropertyPermission "java.vm.specification.name", "read"; permission java.util.PropertyPermission "java.vm.version", "read"; permission java.util.PropertyPermission "java.vm.vendor", "read"; permission java.util.PropertyPermission "java.vm.name", "read"; permission java.net.SocketPermission "localhost:8081", "listen, resolve"; } ; grant codeBase "http://localhost:8081/*" { permission java.security.AllPermission; }; grant codeBase "file:/opt/src/river/trunk/*" { permission java.security.AllPermission; } ; grant codeBase "file:/usr/local/java/lib/*" { permission java.security.AllPermission; }; grant codeBase "http://bluto:8081/*" { permission java.security.AllPermission; } ;
          Hide
          Peter Firmstone added a comment -

          Jonathan,

          Have you still got a copy of the old makefile that ran the qa tests, I wonder if there's an option in there to run jtreg?

          Looks like jtreg is called with GNUmake, however it can be done with ant also.

          Show
          Peter Firmstone added a comment - Jonathan, Have you still got a copy of the old makefile that ran the qa tests, I wonder if there's an option in there to run jtreg? Looks like jtreg is called with GNUmake, however it can be done with ant also.

            People

            • Assignee:
              Unassigned
              Reporter:
              Peter Firmstone
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development