You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@river.apache.org by "Peter Firmstone (JIRA)" <ji...@apache.org> on 2009/04/21 22:51:47 UTC
[jira] Created: (RIVER-304) Reactivate River jtreg tests
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
>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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710467#action_12710467 ]
Peter Jones commented on RIVER-304:
-----------------------------------
> 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).
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712471#action_12712471 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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";
};
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761823#action_12761823 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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
> 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-output-20090928-JC.tar.gz, 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.
Re: [jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by Peter Firmstone <ji...@zeus.net.au>.
Playing around with jtreg, this is something like how you work it, hey
some tests are even passing ;)
To put it simply, jtreg is primarily for Regression testing, to make
sure bugs don't reoccur, although it does unit tests also, seems quite
simple, doesn't look too difficult, be good to have some more
information on setting up these tests though.
bash-3.00$ jtreg -verbose:summary -jdk /usr/jdk/latest
-cpa:../../build/classes/ ./
Passed:
com/sun/jini/action/catchSecurityException/CatchSecurityException.java
Passed: com/sun/jini/config/KeyStores/TestGetKeyStore.java
Passed: com/sun/jini/config/KeyStores/TestGetX500Principal.java
Passed: com/sun/jini/phoenix/ExecOptionPermission/Operations.java
Passed: com/sun/jini/tool/CheckConfigurationFile/TestCheck.java
FAILED:
java/rmi/server/RMIClassLoader/loadProxyClasses/PreferredLoadProxyClasses.java
Passed:
java/rmi/server/Unreferenced/marshalledObjectGet/MarshalledObjectGet.java
Passed: java/rmi/server/Unreferenced/whenOnUnexport/WhenOnUnexport.java
FAILED:
net/jini/activation/Activatable/activateExceptionTest/ActivateExceptionTest.java
FAILED: net/jini/activation/Activatable/activateFailure/ActivateFailure.java
FAILED:
net/jini/activation/Activatable/checkImplClassLoader/CheckImplClassLoader.java
FAILED:
net/jini/activation/Activatable/checkRegisterInLog/CheckRegisterInLog.java
FAILED:
net/jini/activation/Activatable/createPrivateActivable/CreatePrivateActivatable.java
FAILED:
net/jini/activation/Activatable/downloadParameterClass/DownloadParameterClass.java
FAILED:
net/jini/activation/Activatable/downloadSecurityManager/DownloadSecurityManager.java
FAILED:
net/jini/activation/Activatable/forceLogSnapshot/ForceLogSnapshot.java
FAILED: net/jini/activation/Activatable/inactiveGroup/InactiveGroup.java
FAILED: net/jini/activation/Activatable/nestedActivate/NestedActivate.java
FAILED:
net/jini/activation/Activatable/nonExistentActivatable/NonExistentActivatable.java
FAILED:
net/jini/activation/Activatable/restartCrashedService/RestartCrashedService.java
FAILED: net/jini/activation/Activatable/restartService/RestartService.java
FAILED: net/jini/activation/Activatable/terminateGroup/TerminateGroup.java
FAILED:
net/jini/activation/Activatable/unregisterInactive/UnregisterInactive.java
FAILED:
net/jini/activation/Activatable/useProxyAccessor/UseProxyAccessor.java
Passed:
net/jini/activation/ActivatableInvocationHandler/readObject/ReadObject.java
FAILED:
net/jini/activation/ActivationAdmin/getGroupsObjects/GetGroupsObjects.java
FAILED:
net/jini/activation/ActivationSystem/accessControl/AccessControl.java
FAILED:
net/jini/activation/ActivationSystem/bootstrapAttack/BootstrapAttack.java
FAILED:
net/jini/activation/ActivationSystem/ensureRestart/EnsureRestart.java
FAILED:
net/jini/activation/ActivationSystem/unregisterGroup/UnregisterGroup.java
FAILED: net/jini/config/ConfigurationFile/TestParser/TestParser.java
FAILED: net/jini/config/TestAPI/TestConstructor.java
FAILED: net/jini/config/TestAPI/TestGetEntryType.java
FAILED: net/jini/config/TestAPI/TestGetInstance.java
Passed: net/jini/config/TestAPI/TestOverrides.java
Passed: net/jini/config/TestAPI/TestUnicodeEscapesDecodingReader.java
Passed: net/jini/config/TestAbstractConfiguration.java
Passed: net/jini/config/TestEmptyConfiguration.java
Passed:
net/jini/constraints/BasicMethodConstraints/getConstraints/GetConstraints.java
Passed: net/jini/constraints/BasicMethodConstraints/ordering/Ordering.java
Passed: net/jini/constraints/basicOperations/BasicOperations.java
Passed: net/jini/constraints/readObject/ReadObject.java
Passed: net/jini/iiop/echo/ConnectedExport.java
Passed: net/jini/iiop/echo/NonIiopExport.java
Passed: net/jini/iiop/echo/UnconnectedExport.java
FAILED:
net/jini/io/MarshalInputStream/verifyWithEqualLoaders/VerifyWithEqualLoaders.java
Passed:
net/jini/jeri/BasicInvocationDispatcher/checkClientPermission/CheckClientPermission.java
Passed:
net/jini/jeri/BasicInvocationDispatcher/suppressStackTraces/SuppressStackTraces.java
Passed:
net/jini/jeri/BasicInvocationHandler/serverStackTrace/ServerStackTrace.java
Passed:
net/jini/jeri/BasicInvocationHandler/unmarshalUnexpectedException/UnmarshalUnexpectedException.java
FAILED:
net/jini/jeri/BasicJeriExporter/dgcServerExposure/DgcServerExposure.java
Passed:
net/jini/jeri/BasicJeriExporter/globalListenLock/GlobalListenLock.java
FAILED: net/jini/jeri/BasicJeriExporter/operations/Operations.java
Passed: net/jini/jeri/BasicJeriExporter/sameClassCheck/SameClassCheck.java
Passed: net/jini/jeri/BasicJeriTrustVerifier/BjtvSubclassTest.java
FAILED:
net/jini/jeri/connection/ConnectionManager/overlocking/Overlocking.java
Passed:
net/jini/jeri/connection/ConnectionManager/saturation/Saturation.java
Passed: net/jini/jeri/http/connectionReuse/Test.java
FAILED: net/jini/jeri/http/echo/EchoImpl.java
Passed:
net/jini/jeri/internal/runtime/getRemoteInterfaces/GetRemoteInterfaces.java
Passed:
net/jini/jeri/internal/runtime/runtimeThreadInheritanceLeak/RuntimeThreadInheritanceLeak.java
FAILED: net/jini/jeri/kerberos/RegressionTests/runListenEndpointTest.sh
FAILED: net/jini/jeri/kerberos/UnitTests/runTestEndpoints.sh
FAILED: net/jini/jeri/kerberos/UnitTests/runTestPerformance.sh
Passed: net/jini/jeri/kerberos/UnitTests/TestVerifier.java
FAILED: net/jini/jeri/ssl/UnitTests/TestConnectionContext.java
FAILED: net/jini/jeri/ssl/UnitTests/TestEndpoint.java
FAILED: net/jini/jeri/ssl/UnitTests/TestEndpointHttps.sh
FAILED: net/jini/jeri/ssl/UnitTests/TestEndpointInternal.java
FAILED: net/jini/jeri/ssl/UnitTests/TestEndpointInternalHttps.sh
FAILED: net/jini/jeri/ssl/UnitTests/TestPerformance.java
FAILED: net/jini/jeri/ssl/UnitTests/TestPerformanceHttps.sh
FAILED: net/jini/jeri/ssl/UnitTests/TestRMI.java
FAILED: net/jini/jeri/ssl/UnitTests/TestRMIHttps.sh
FAILED: net/jini/jeri/ssl/UnitTests/TestServerEndpoint.java
FAILED: net/jini/jeri/ssl/UnitTests/TestServerEndpointHttps.sh
FAILED: net/jini/jeri/ssl/UnitTests/TestTwoEndpoints.java
FAILED: net/jini/jeri/ssl/UnitTests/TestUtilities.java
FAILED: net/jini/jeri/ssl/UnitTests/TestVerifier.java
FAILED: net/jini/jeri/ssl/UnitTests/TestWeakSoftTable.java
Passed: net/jini/jeri/tcp/connectTimeout/TestConnectTimeout.java
FAILED: net/jini/jeri/tcp/localHostExposure/LocalHostExposure.java
Passed: net/jini/jeri/tcp/outOfThreads/OutOfThreads.java
output cut.
Cheers,
Peter.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-304:
----------------------------------
Attachment: ant.html
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.
> 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
>
>
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762391#action_12762391 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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.
> 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-output-20090928-JC.tar.gz, jtreg_stdout_errout.txt, JTreport-jdk1.5-qatests-trunk.tgz, JTreport.tgz, JTwork-jdk5-qatests-trunk.tgz, JTwork.tgz, test-results6-oct-09.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.
[jira] Issue Comment Edited: (RIVER-304) Reactivate River jtreg
tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760129#action_12760129 ]
Jonathan Costers edited comment on RIVER-304 at 9/27/09 4:35 PM:
-----------------------------------------------------------------
Results of first jtreg run from Ant build process are attached above
was (Author: jcosters):
Results of first jtreg run from Ant build process
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761404#action_12761404 ]
Jonathan Costers commented on RIVER-304:
----------------------------------------
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
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.
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12714914#action_12714914 ]
Peter Jones commented on RIVER-304:
-----------------------------------
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.
> 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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Sim IJskes (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sim IJskes updated RIVER-304:
-----------------------------
Component/s: build
> Reactivate River jtreg tests
> ----------------------------
>
> Key: RIVER-304
> URL: https://issues.apache.org/jira/browse/RIVER-304
> Project: River
> Issue Type: Test
> Components: build
> Environment: JDK 1.5 or later with jtreg test suite http://www.openjdk.org/jtreg/
> Reporter: Peter Firmstone
> Attachments: ant.html, jtreg-20100827-JC.log, jtreg-output-20090928-JC.tar.gz, jtreg_stdout_errout.txt, JTreport-jdk1.5-qatests-trunk.tgz, JTreport.tgz, JTwork-jdk5-qatests-trunk.tgz, JTwork.tgz, test-results6-oct-09.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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762015#action_12762015 ]
Jonathan Costers commented on RIVER-304:
----------------------------------------
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
> 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-output-20090928-JC.tar.gz, 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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Costers updated RIVER-304:
-----------------------------------
Attachment: jtreg-20100827-JC.log
I just ran the complete jtreg suite again (complete log attached):
Test results: passed: 128; failed: 10
> 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-20100827-JC.log, jtreg-output-20090928-JC.tar.gz, jtreg_stdout_errout.txt, JTreport-jdk1.5-qatests-trunk.tgz, JTreport.tgz, JTwork-jdk5-qatests-trunk.tgz, JTwork.tgz, test-results6-oct-09.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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-304:
----------------------------------
Attachment: test-results6-oct-09.tgz
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.
> 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-output-20090928-JC.tar.gz, jtreg_stdout_errout.txt, JTreport-jdk1.5-qatests-trunk.tgz, JTreport.tgz, JTwork-jdk5-qatests-trunk.tgz, JTwork.tgz, test-results6-oct-09.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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-304:
----------------------------------
Attachment: jtreg_stdout_errout.txt
JTwork.tgz
JTreport.tgz
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;
};
> 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.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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12760128#action_12760128 ]
Jonathan Costers commented on RIVER-304:
----------------------------------------
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.
> 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.
Re: [jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by Peter Firmstone <ji...@zeus.net.au>.
I think it's something to do with the directory structure of the code
base server, will look into it further tomorrow.:
HTTPD: using /vob/jive/lib/tools.jar on port 8081 serving /vob/jive/lib-dl
RMID: starting rmid...
JAVAVM: command = /usr/j2se/jre/bin/java -Djava.security.policy=/opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader/rmid.security.policy -Djava.rmi.server.codebase="http://10.1.1.2:8081/phoenix-dl.jar http://10.1.1.2:8081/jsk-dl.jar" -Dtest.src=/opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader -Dtest.classes=/opt/src/river/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/checkImplClassLoader -Djsk.home=/vob/jive -jar /vob/jive/lib/phoenix.jar /opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader/rmid.config
JavaVM: parsed command: [/usr/j2se/jre/bin/java, -Djava.security.policy=/opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader/rmid.security.policy, -Djava.rmi.server.codebase=http://10.1.1.2:8081/phoenix-dl.jar http://10.1.1.2:8081/jsk-dl.jar, -Dtest.src=/opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader, -Dtest.classes=/opt/src/river/trunk/qa/jtreg/JTwork/classes/net/jini/activation/Activatable/checkImplClassLoader, -Djsk.home=/vob/jive, -jar, /vob/jive/lib/phoenix.jar, /opt/src/river/trunk/qa/jtreg/net/jini/activation/Activatable/checkImplClassLoader/rmid.config]
null: Unable to access jarfile /vob/jive/lib/phoenix.jar
Peter Jones (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705123#action_12705123 ]
>
> Peter Jones commented on RIVER-304:
> -----------------------------------
>
> 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.
>
>
>
>> 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.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
>>>>
>>>>
>>>>
>
>
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12705123#action_12705123 ]
Peter Jones commented on RIVER-304:
-----------------------------------
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.
> 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.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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712935#action_12712935 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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.
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762063#action_12762063 ]
Peter Jones commented on RIVER-304:
-----------------------------------
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.)
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762296#action_12762296 ]
Jonathan Costers commented on RIVER-304:
----------------------------------------
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.
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762004#action_12762004 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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?
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724931#action_12724931 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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
> 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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Costers updated RIVER-304:
-----------------------------------
Attachment: jtreg-output-20090928-JC.tar.gz
Results of first jtreg run from Ant build process
> 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-output-20090928-JC.tar.gz, 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.
[jira] Updated: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Peter Firmstone updated RIVER-304:
----------------------------------
Attachment: JTwork-jdk5-qatests-trunk.tgz
JTreport-jdk1.5-qatests-trunk.tgz
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 \
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "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.
[jira] Issue Comment Edited: (RIVER-304) Reactivate River jtreg
tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12761404#action_12761404 ]
Jonathan Costers edited comment on RIVER-304 at 10/1/09 4:43 PM:
-----------------------------------------------------------------
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
was (Author: jcosters):
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
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.
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Jonathan Costers (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762018#action_12762018 ]
Jonathan Costers commented on RIVER-304:
----------------------------------------
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
> 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-output-20090928-JC.tar.gz, 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Jones (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12710475#action_12710475 ]
Peter Jones commented on RIVER-304:
-----------------------------------
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.
> 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.
[jira] Commented: (RIVER-304) Reactivate River jtreg tests
Posted by "Peter Firmstone (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/RIVER-304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12762017#action_12762017 ]
Peter Firmstone commented on RIVER-304:
---------------------------------------
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.
> 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-output-20090928-JC.tar.gz, 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.