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 Mon, 22 Nov 2010 10:02:49 GMT
Patricia Shanahan wrote:
> On 11/21/2010 11:05 AM, Sim IJskes - QCG wrote:
>> On 11/21/2010 08:03 PM, Sim IJskes - QCG wrote:
>>> On 11/21/2010 06:14 PM, Patricia Shanahan wrote:
>>>>>>>> does not have required permission:
>>>>>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>>> In any case, I have some good questions, and this is a promising 
>>>> line of
>>>> inquiry, because file: URL construction interacts with file path name
>>>> construction, which is different between Windows and the other systems
>>>> on which River has been tested.
>>> Could the code in SharedActivationPolicyPermission.init() be the 
>>> culprit?
>>> What about a test for scheme = 'file' and then take a separate path
>>> through code constructed with:
>>> new File(url.toURI()).getName().getAbsolutePath() ?
>> Without the getName() call.... :]
> This approach seems good. The test I'm currently working on passes if 
> I use the following to get the FilePermission object:
> new FilePermission(new File(new 
> URL(policy).getPath()).getAbsolutePath(),"read")
> However, I am not sure about the correctness, relative to general 
> River policies, of the exception handling in the init method. If it 
> gets a MalformedUrlException it just goes ahead and tries to use the 
> unmodified policy String in the FilePermission constructor.
> In addition to that case, I need to decide what to do if the policy 
> String is a well formed URL, but does not have a file path component. 
> Presumably a FilePermission does not make sense in that case???
> Note that the mapping is not just for file: URLs. The comment at the 
> start of the init method uses an http: example for the reason for 
> doing the mapping.
> Patricia
It's worth noting, that the UnresolvedPermissions had not been resolved, 
meaning that their path string had not yet been converted as 
SharedActivationPolicyPermission.init() had not been called, for any 
permissions that remained unresolved.

If these permissions had been resolved, their resolved form would appear 
in the ProtectionDomain.toString() output, when a Permission is 
resolved  all belonging to the same class are resolved and added to a 
PermissionCollection on which implies(Permission) is called, this is 
done, in case two Permission's combined imply the checked Permission.

There are two things to check, did the policy successfully resolve the 
permission? See UnresolvedPermission.resolve If not, why? If it did, why 
didn't it imply.  You'll need to set some breakpoints in 



View raw message