river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Build failed in Hudson: River-trunk-QA-windows #7
Date Sun, 21 Nov 2010 03:49:03 GMT
Patricia Shanahan wrote:
> On 11/20/2010 2:40 PM, Peter Firmstone wrote:
>> Peter Firmstone wrote:
>>> Patricia Shanahan wrote:
>>>> On 11/19/2010 10:06 AM, Sim IJskes - QCG wrote:
>>>>> On 11/19/2010 06:20 PM, Apache Hudson Server wrote:
>>>>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
>>>>>
>>>>>> [java] # of tests started = 1410
>>>>>> [java] # of tests completed = 1410
>>>>>> [java] # of tests skipped = 46
>>>>>> [java] # of tests passed = 1363
>>>>>> [java] # of tests failed = 47
>>>>>
>>>>> https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk/trunk/qa/result/index.html

>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Some tests failed on policy permissions (so it looks), any change 
>>>>> that
>>>>> this is windows related? slash vs backslash and driveletter?
>>>>
>>>> I have run the first failing test,
>>>> com/sun/jini/test/impl/start/ActivateWrapperActivateDescTest.td,
>>>> under WindowsXP, and reproduced the failure. The test passes on an
>>>> identical checkout, compiled and run with the same JDK version, on a
>>>> Ubuntu VirtualBox.
>>>>
>>>> That creates a strong presumption that we are indeed dealing with a
>>>> Windows related issue, such as the horrible Windows file naming.
>>>>
>>>> The first error in the log is:
>>>>
>>>> [java] com.sun.jini.qa.harness.TestException: Unexpected exception
>>>> starting service; nested exception is:
>>>> [java] Problem creating service for sharedGroupImpl; nested exception
>>>> is:
>>>> [java] exception constructing object; nested exception is:
>>>> [java] java.lang.SecurityException: ProtectionDomain ProtectionDomain
>>>> (file:/C:/apache2/River/lib/group.jar <no signer certificates>)
>>>> [java] null
>>>> [java] <no principals>
>>>>
>>>> The failure is during set-up, so it is quite likely that a lot of
>>>> tests are affected by the same problem.
>>>>
>>>> Any advice on how to check the signer certificates?
>>>>
>>>> Thanks,
>>>>
>>>> Patricia
>>>>
>>>>
>>>>
>>>
>>> Your failure isn't caused by <no signer certificates>, that's just
>>> information printed from the ProtectionDomain, did the failing
>>> ProtectionDomain list the Permissions?
>>>
>>> What was the Permission that failed?
>>>
>>> When ProtectionDomain.toString is called, it merges the dynamic
>>> Permissions from the policy with the static Permissions in the
>>> ProtectionDomain and prints them all out, useful for debugging.
>
> I'm not 100% sure how to answer the question, so I've uploaded the 
> output as http://www.patriciashanahan.com/apache/failingTest.txt
>
>> I wonder if the policy file has a Permission grant with a bad path? That
>> might explain the missing permission.
>>
>
> Are path comparisons done using the File equals method, or String equals?
>
> Patricia
>
>

The permission that's failing is:

does not have required permission: (com.sun.jini.start.SharedActivationPolicyPermission file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)

Interestingly the policy has not resolved:

(unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\defaultgroup.policy
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\policy.all
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\all.policy
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission file:C:\apache2\River\qa\harness\policy\sec-jeri-group.policy
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/defaultgroup.policy
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/policy.all
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/all.policy
null)
     [java]  (unresolved com.sun.jini.start.SharedActivationPolicyPermission jar:file:C:\apache2\River\qa\lib\jiniharness.jar!/harness/policy/sec-jeri-group.policy
null)

This means that the class 
com.sun.jini.start.SharedActivationPolicyPermission was not visible to 
the policy file implementation, which is normal, since it is loaded by 
the parent java extension classloader.

What isn't normal however is the SharedActivationPolicyPermission should 
later be resolved when Policy.implies(ProtectionDomain, Permission) is 
called.

As you can see from the output, the policy has been read correctly and 
has the needed permission, albeit unresolved.

This tends to indicate that there may be a class path issue with start.jar

Hope this helps.

Cheers,

Peter.

Mime
View raw message