You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Patricia Shanahan <pa...@acm.org> on 2010/11/02 08:47:27 UTC

qa.run failures

I started an "ant qa.run" with the latest trunk everything. It is 
getting numerous permission-related failures. The failures persist 
despite rebooting the virtual machine and doing a clean build. Are there 
any changes in how to run the tests?

Here's an example:

      [java] Running 
com/sun/jini/test/spec/loader/pref/preferredClassLoader/Constructor.td
      [java] Time is Tue Nov 02 00:36:56 PDT 2010
      [java] Starting test in separate process with command:
      [java] /usr/lib/jvm/java-6-openjdk/jre/bin/java 
-Djava.security.policy=file:/home/pats/River/qa/src/com/sun/jini/test/spec/loader/pref/preferredClassLoader/loader.policy 
-cp 
/home/pats/River/qa/lib/jiniharness.jar:/home/pats/River/qa/lib/jinitests.jar:/home/pats/River/lib/jsk-platform.jar:/home/pats/River/lib/jsk-lib.jar 
-client 
-Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext 
-Dcom.sun.jini.jsk.port=8080 -Dcom.sun.jini.qa.port=9081 
-Dcom.sun.jini.jsk.home=/home/pats/River 
-Dcom.sun.jini.qa.home=/home/pats/River/qa 
-Dcom.sun.jini.qa.harness.harnessJar=/home/pats/River/qa/lib/jiniharness.jar 
-Dcom.sun.jini.qa.harness.testJar=/home/pats/River/qa/lib/jinitests.jar 
-Dcom.sun.jini.qa.harness.runjiniserver=false 
-Dcom.sun.jini.qa.harness.runkitserver=false 
-Djava.security.properties=file:/home/pats/River/qa/harness/trust/dynamic-policy.properties 
-Dcom.sun.jini.qa.harness.testhosts= 
-Djava.util.logging.config.file=/home/pats/River/qa/src/com/sun/jini/test/resources/qa1.logging 
-Dcom.sun.jini.test.home=/home/pats/River/qa 
-Dcom.sun.jini.test.port=8082 
-Dcom.sun.jini.qa.harness.policies=file:/home/pats/River/qa/src/com/sun/jini/test/resources/jinitest.policy 
-Djava.ext.dirs=/usr/lib/jvm/java-6-openjdk/jre/lib/ext:/usr/java/packages/lib/ext:/home/pats/River/qa/lib-ext:/home/pats/River/lib-ext 
com.sun.jini.qa.harness.MasterTest 
com/sun/jini/test/spec/loader/pref/preferredClassLoader/Constructor.td
      [java] Exception in thread "main" 
java.lang.ExceptionInInitializerError
      [java] 	at 
com.sun.jini.qa.harness.MasterTest.main(MasterTest.java:101)
      [java] Caused by: java.security.AccessControlException: access 
denied (java.lang.RuntimePermission getenv.SOUL)
      [java] 	at 
java.security.AccessControlContext.checkPermission(AccessControlContext.java:342)
      [java] 	at 
java.security.AccessController.checkPermission(AccessController.java:553)
      [java] 	at 
java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
      [java] 	at java.lang.System.getenv(System.java:846)
      [java] 	at 
com.sun.jini.qa.harness.HeartOfTheMachine.<clinit>(HeartOfTheMachine.java:19)
      [java] 	... 1 more
      [java]

Re: qa.run failures

Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/02/2010 09:05 AM, Patricia Shanahan wrote:
>>
>> I'm trying again with "ant clean" as well, but I think it does no more
>> than "ant all.clean".
>
> Still fails. It also fails if I do a run-tests for the specific test.

And if you change the relevant policy files to allow for

(java.lang.RuntimePermission getenv.SOUL)

Gr. Sim

Re: qa.run failures

Posted by Patricia Shanahan <pa...@acm.org>.
On 11/2/2010 12:59 AM, Patricia Shanahan wrote:
> On 11/2/2010 12:54 AM, Sim IJskes - QCG wrote:
>> On 11/02/2010 08:47 AM, Patricia Shanahan wrote:
>>> I started an "ant qa.run" with the latest trunk everything. It is
>>> getting numerous permission-related failures. The failures persist
>>> despite rebooting the virtual machine and doing a clean build. Are there
>>> any changes in how to run the tests?
>>
>> No, its a bug (missing config). Can you fix it? Its the:
>>
>> [java] Caused by: java.security.AccessControlException: access denied
>> (java.lang.RuntimePermission getenv.SOUL)
>>
>> Permission that is missing.
>>
>> How did you perform a clean build? Because i got this error as well, and
>> it was cured if i remember correctly by a 'ant clean'. But i haven't run
>> the whole QA before checking in.
>
> ant all.clean; ant all.build
>
> I'm trying again with "ant clean" as well, but I think it does no more
> than "ant all.clean".

Still fails. It also fails if I do a run-tests for the specific test.

Patricia

Re: qa.run failures

Posted by Patricia Shanahan <pa...@acm.org>.
On 11/2/2010 12:54 AM, Sim IJskes - QCG wrote:
> On 11/02/2010 08:47 AM, Patricia Shanahan wrote:
>> I started an "ant qa.run" with the latest trunk everything. It is
>> getting numerous permission-related failures. The failures persist
>> despite rebooting the virtual machine and doing a clean build. Are there
>> any changes in how to run the tests?
>
> No, its a bug (missing config). Can you fix it? Its the:
>
> [java] Caused by: java.security.AccessControlException: access denied
> (java.lang.RuntimePermission getenv.SOUL)
>
> Permission that is missing.
>
> How did you perform a clean build? Because i got this error as well, and
> it was cured if i remember correctly by a 'ant clean'. But i haven't run
> the whole QA before checking in.

ant all.clean; ant all.build

I'm trying again with "ant clean" as well, but I think it does no more 
than "ant all.clean".

Patricia



Re: qa.run failures

Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/02/2010 08:47 AM, Patricia Shanahan wrote:
> I started an "ant qa.run" with the latest trunk everything. It is
> getting numerous permission-related failures. The failures persist
> despite rebooting the virtual machine and doing a clean build. Are there
> any changes in how to run the tests?

No, its a bug (missing config). Can you fix it? Its the:

      [java] Caused by: java.security.AccessControlException: access 
denied (java.lang.RuntimePermission getenv.SOUL)

Permission that is missing.

How did you perform a clean build? Because i got this error as well, and 
it was cured if i remember correctly by a 'ant clean'. But i haven't run 
the whole QA before checking in.

Gr. Sim