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 05:45:26 GMT
Peter Firmstone wrote:
> 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
>>
>>

Neither, it uses FilePermission.implies(Permission) internally.

Cheers,

Peter.


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