river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Firmstone (JIRA)" <j...@apache.org>
Subject [jira] Commented: (RIVER-304) Reactivate River jtreg tests
Date Sat, 23 May 2009 23:18:45 GMT

    [ 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

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

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

View raw message