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 17:14:13 GMT
On 11/21/2010 8:29 AM, Jonathan Costers wrote:
> 2010/11/21 Patricia Shanahan<pats@acm.org>
>
>> Patricia Shanahan wrote:
>>
>>> Jonathan Costers wrote:
>>> ...
>>>
>>>> does not have required permission:
>>>>>> (com.sun.jini.start.SharedActivationPolicyPermission
>>>>>> file:/C:/apache2/River/qa/harness/policy/defaultgroup.policy)
>>>>>>
>>>>> ...
>>>
>>>> What this means is that it has no permission to use file:*/*C:/.... , the
>>>> policies only give permission to file:C:\... Note extra / between file:
>>>> and
>>>> C:
>>>>
>>>
>>> Well spotted! Thanks.
>>>
>> ...
>>
>> I did a quick scan of the log,
>> http://www.patriciashanahan.com/apache/failingTest.txt, and the first
>> appearance of an extra "/" is in the first "-D" parameter on the test start
>> command:
>>
>>      [java] Starting test in separate process with command:
>>      [java] 'C:\Program Files (x86)\Java\jdk1.6.0_22\jre\bin\java'
>> -Djava.security.policy=file:/C:/apache2/River/qa/harness/policy/defaulttest.policy
>> ...
>>
>> This may not be the direct cause of the failures, but is certainly worth
>> investigating. Making all file: URIs correct, even with Windows' annoying
>> path structure, seems like a reasonable objective for avoiding Windows-only
>> bugs. At some point, I'll probably find some idiom or shared method that
>> really is the root cause of the failures.
>>
>>
> Line 146 in qa/src/com/sun/jini/qa/resources/qaDefaults.properties is
> probably the "root cause".
> The<url>  tag translates a relative path into an URL.
> However, one could argue that this (file:/C:/...) is a correct URL and that
> the policy files really should accept it.

I'll investigate this by experimenting with java.net.URI, as well as
re-reading the relevant documents. If the "/" before the drive letter is
required - to indicate absolute rather than relative path in the URL -
then the problem may be in how the permissions were originally set up.

Incidentally, Firefox accepts from 0 through 3 "/" characters between
the "file:" and the drive letter, but browsers often accept things that
are not strictly correct.

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.

Patricia

Mime
View raw message