[jira] Commented: (RIVER-304) Reactivate River jtreg tests

["Peter Firmstone (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759973#action_12759973 ] 

Peter Firmstone commented on RIVER-304:
---------------------------------------

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
     <ci...@zeus.net.au> : Echo implementation
     for testing basic HTTP endpoint functionality.


       Execution failed: exit code 1

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


       Execution failed: exit code 255

   * net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh
     <ci...@zeus.net.au> : Test the
     KerberosEndpoint and KerberosServerEndpoint classes.
   * net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh
     <ci...@zeus.net.au> : Tests the end to end
     performance of Kerberos provider. 

> Reactivate River jtreg tests
> ----------------------------
>
>                 Key: RIVER-304
>                 URL: https://issues.apache.org/jira/browse/RIVER-304
>             Project: River
>          Issue Type: Test
>         Environment: JDK 1.5 or later with jtreg test suite http://www.openjdk.org/jtreg/ 
>            Reporter: Peter Firmstone
>         Attachments: ant.html, jtreg_stdout_errout.txt, JTreport-jdk1.5-qatests-trunk.tgz, JTreport.tgz, JTwork-jdk5-qatests-trunk.tgz, JTwork.tgz
>
>
> 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
> >>
> >>   

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.