river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patricia Shanahan <p...@acm.org>
Subject Re: Build failed in Hudson: River-trunk-QA-windows #7
Date Sun, 21 Nov 2010 23:53:18 GMT
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 

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.


View raw message