[RIVER-304] Reactivate River jtreg tests

• Type: Test
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Fix Version/s: River_3.0.0
• Component/s: build

Environment

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

• Assignee: Unassigned
• Reporter: Peter Firmstone
• Created: 21/Apr/09 20:49
• Updated: 05/Dec/15 10:14
• Resolved: 05/Dec/15 10:14

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
>>
>>

Issue Links

• is related to: RIVER-319 Change River Build Dist structure to support jtreg test automation
• is related to: RIVER-223 test: jtreg/net/jini/jeri/tcp/connectTimeout/TestConnectTimeout fails on Linux
• relates to: RIVER-230 (mux) SelectionManager catch Error block assumes getMessage() returns non-null
• relates to: RIVER-303 Add "test" directory to the jtsk trunk for unit tests

Sub-Tasks

• Create proxy server implementation for jtreg test of net/jini/jeri/http/echo/EchoImpl.java: Open
• KDC (Key Distribution Center) Server for kerberos tests: Open
• Change River Build Dist structure to support jtreg test automation: Resolved