You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Apache Hudson Server <hu...@hudson.apache.org> on 2010/11/19 18:20:04 UTC
Build failed in Hudson: River-trunk-QA-windows #7
See <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/7/>
------------------------------------------
[...truncated 10876 lines...]
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeIfExistsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeIfExistsWaitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeNO_WAITTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeReadTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionTakeWaitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteLeaseANYTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteLeaseFOREVERTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteNegativeLeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeIfExistsNotifyTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeIfExistsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeNotifyTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTakeTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotTransactionWriteTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteLeaseANYTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteLeaseFOREVERTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteNegativeLeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/javaspace/conformance/snapshot/SnapshotWriteTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/AdminIFShutdownTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/AdminIFTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseExpireCancelTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseExpireRenewTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseMapTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/LeaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloCreateShutdownTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloIFTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/MahaloImplReadyStateTest.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mercury.ActivatableMercuryVerifier com.sun.jini.qa.harness.SkipConfigTestVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/NestableServerTransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/NestableTransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest2.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest3.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest4.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/PrepareAndCommitExceptionTest5.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/RandomStressTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/ServerTransactionEqualityTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/ServerTransactionToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TransactionCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TransactionManagerCreatedToStringTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullActivationConfigEntries.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mahalo.ActivatableMahaloVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullConfigEntries.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrImplNullRecoveredLocators.td
[java] Test Skipped: verifiers are: com.sun.jini.test.impl.mahalo.ActivatableMahaloVerifier
[java] -----------------------------------------
[java] com/sun/jini/test/impl/mahalo/TxnMgrProxyEqualityTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/AsynchAbortOnCommitTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/AsynchAbortOnPrepareTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/CommitExpiredTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/CommitTimeoutTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/GetStateTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/JoinIdempotentTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/JoinWhileActiveTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/ManyParticipantsTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/PrepareTimeoutTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/RollBackErrorTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/RollForwardErrorTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java] com/sun/jini/test/spec/txnmanager/TwoPhaseTest.td
[java] Test Passed: OK
[java]
[java] -----------------------------------------
[java]
[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
[java]
[java] -----------------------------------------
[java]
[java] Date finished:
[java] Fri Nov 19 17:16:51 GMT 2010
[java] Time elapsed:
[java] 90295 seconds
[java]
[java] Java Result: 1
collect-result:
[copy] Copying 1 file to <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result>
[copy] Copying 1 file to <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result>
[zip] Building zip: <https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\result\qaresults-amd64-Windows> Server 2008-1.6.0_17.zip
BUILD FAILED
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\build.xml>:2065: The following error occurred while executing this line:
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\build.xml>:341: The following error occurred while executing this line:
<https://hudson.apache.org/hudson/job/River-trunk-QA-windows/ws/jtsk\trunk\qa\build.xml>:315: condition satisfied
Total time: 1542 minutes 54 seconds
Publishing Javadoc
Archiving artifacts
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 12:53 AM, Patricia Shanahan wrote:
> 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???
Exactly. We can verify it in river sense, by including logoutput and a
exception in this case.
Also we should make sure the File is not checked for existance, not the
least because of the /* /- ends.
> 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.
Yes, totally confusing. Where can we find an example in the JDK that
explains the meaning of the FilePermission? If we can be sure it can
only be a real filepath and not a jar or http reference, we could
include assert like checks.
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 06:05 PM, Sim IJskes - QCG wrote:
> On 11/22/2010 06:02 PM, Sim IJskes - QCG wrote:
>> Hmm, how can we be sure what a FilePermission string looks like on a
>> future system? It is a bug to pass a URL, but i'm back peddling on
>> throwing an exception. A warning maybe, or a logging statement?
>
> Something that we can enable during testing, and will never cause
> problems in production environments, was my line of thinking.
Stripping '*' and '-' from the end, and then new File(str).getPath()
will cause FileSystem.normalize(), would this check for illegal file
specification? FileSystem is package private so no direct access.
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 06:02 PM, Sim IJskes - QCG wrote:
> Hmm, how can we be sure what a FilePermission string looks like on a
> future system? It is a bug to pass a URL, but i'm back peddling on
> throwing an exception. A warning maybe, or a logging statement?
Something that we can enable during testing, and will never cause
problems in production environments, was my line of thinking.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 05:39 PM, Patricia Shanahan wrote:
> After looking at all this, I'm thinking in terms of pushing the problem
> up a layer, and requiring a File argument instead of a String. That
> makes the idea of local File'ness explicit.
That doesnt look right to me. A File with a name ending in - or * is not
a true File.
> There is only one use of SharedActivationPolicyPermission in the River
> production code, in ActivateWrapper. The remaining calls are all tests
> which we can modify or drop as appropriate. I'm inclined to the view
> that a test that passes a string that does not conform to FilePermission
> policy string semantics should expect an IllegalArgumentException from
> the constructor.
Hmm, how can we be sure what a FilePermission string looks like on a
future system? It is a bug to pass a URL, but i'm back peddling on
throwing an exception. A warning maybe, or a logging statement?
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 11/22/2010 05:39 PM, Patricia Shanahan wrote:
> I think I understand what you are saying, but I'm not 100% sure, so I'm
> going to repeat back the message I'm getting:
>
> The implementation of SharedActivationPolicyPermission depends on
> FilePermission. Its Javadoc comment requires a policy string argument
> that conforms to the FilePermission policy string semantics.
>
> A URL, in general, is not a valid FilePermission policy string. On the
> other hand, a File path is. Incidentally, I've tested handling of the
> FilePermission wildcards in the File class, and it all works.
>
> File can do the "/" conversion correctly and automatically for the
> system on which it is run. Doing the conversion on the file path portion
> of the URL makes the test case I've been working on pass on both Windows
> and Ubuntu.
>
> Even if we make no change in the actual interface,
> SharedActivationPolicyPermission should enforce its stated requirement
> that the policy string constructor argument conform to FilePermssion
> policy semantics.
Yes! RST 559!
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/22/2010 7:22 AM, Sim IJskes - QCG wrote:
>>> There are a lot of
>>> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
>>> calls and a lot of
>>> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
>>> "policy" + fs + "policy.all");
>>> calls.
>>
>> I think we established earlier that "resendes" is used to represent a
>> non-existent host.
>
> Yes, i hadn't forgotten, but is it a bug or intentional.
>
> The second one is a relative url, the first one isn't.
>
> When we look at the javadocs for SharedActivationPolicyPermission the
> policy string argument has the same semantics as FilePermission.
> FilePermission has no URL, so SharedActivationPolicyPermission should
> not be a URL.
>
> Flawed reasoning? Either the testcases with URL were undetected bugs, or
> the javadoc for SharedActivationPolicyPermission is a bug.
>
> The URL stuff in init() is just enlisted to do some FileSeparator
> conversion, if the javadoc is right.
>
> Gr. Sim
>
> P.S. Bob? Any change that little birdie you talked about will tell us
> the solution?
>
I think I understand what you are saying, but I'm not 100% sure, so I'm
going to repeat back the message I'm getting:
The implementation of SharedActivationPolicyPermission depends on
FilePermission. Its Javadoc comment requires a policy string argument
that conforms to the FilePermission policy string semantics.
A URL, in general, is not a valid FilePermission policy string. On the
other hand, a File path is. Incidentally, I've tested handling of the
FilePermission wildcards in the File class, and it all works.
File can do the "/" conversion correctly and automatically for the
system on which it is run. Doing the conversion on the file path portion
of the URL makes the test case I've been working on pass on both Windows
and Ubuntu.
Even if we make no change in the actual interface,
SharedActivationPolicyPermission should enforce its stated requirement
that the policy string constructor argument conform to FilePermssion
policy semantics.
After looking at all this, I'm thinking in terms of pushing the problem
up a layer, and requiring a File argument instead of a String. That
makes the idea of local File'ness explicit.
There is only one use of SharedActivationPolicyPermission in the River
production code, in ActivateWrapper. The remaining calls are all tests
which we can modify or drop as appropriate. I'm inclined to the view
that a test that passes a string that does not conform to FilePermission
policy string semantics should expect an IllegalArgumentException from
the constructor.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
>> There are a lot of
>> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
>> calls and a lot of
>> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
>> "policy" + fs + "policy.all");
>> calls.
>
> I think we established earlier that "resendes" is used to represent a
> non-existent host.
Yes, i hadn't forgotten, but is it a bug or intentional.
The second one is a relative url, the first one isn't.
When we look at the javadocs for SharedActivationPolicyPermission the
policy string argument has the same semantics as FilePermission.
FilePermission has no URL, so SharedActivationPolicyPermission should
not be a URL.
Flawed reasoning? Either the testcases with URL were undetected bugs, or
the javadoc for SharedActivationPolicyPermission is a bug.
The URL stuff in init() is just enlisted to do some FileSeparator
conversion, if the javadoc is right.
Gr. Sim
P.S. Bob? Any change that little birdie you talked about will tell us
the solution?
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/22/2010 6:45 AM, Sim IJskes - QCG wrote:
> On 22-11-10 00:53, Patricia Shanahan wrote:
>> 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.
>
> I think we need to stick to the JDK definition of a FilePermission, and
> that is a path. There are references in the docs how a FilePermission is
> used. And also a clear use in the FileInputStream(File file) method.
>
> It calls the File.getPath() method there, in order to do a
> SecurityManager.checkRead(String file).
>
> What i can see, is that in the specific qatest, it gets always be called
> with a file: url.
>
> There are a lot of
> new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
> calls and a lot of
> new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
> "policy" + fs + "policy.all");
> calls.
I think we established earlier that "resendes" is used to represent a
non-existent host.
> the resendes seems wrong, the ones starting with fs look right (although
> a driveletter spec is missing).
>
> Did we find a (non-related) bug?
I'm not sure. I'm currently running a QA test with a simple form of the
fix to use File to convert the path to system dependent form. So far, it
has passed 1215 tests, skipped 42, and failed 2. The change has
definitely fixed multiple failures. Interestingly, the two failures are
new, but do not superficially look related to the permission change.
I will go through some basic checks - rebooting my system, reverting the
change and running the failing tests etc. - before starting detailed
debug on them.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
On 22-11-10 00:53, Patricia Shanahan wrote:
> 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.
I think we need to stick to the JDK definition of a FilePermission, and
that is a path. There are references in the docs how a FilePermission is
used. And also a clear use in the FileInputStream(File file) method.
It calls the File.getPath() method there, in order to do a
SecurityManager.checkRead(String file).
What i can see, is that in the specific qatest, it gets always be called
with a file: url.
There are a lot of
new SharedActivationPolicyPermission("http://resendes:8080/policy.all");
calls and a lot of
new SharedActivationPolicyPermission( fs + "vob" + fs + "jive" + fs +
"policy" + fs + "policy.all");
calls.
the resendes seems wrong, the ones starting with fs look right (although
a driveletter spec is missing).
Did we find a (non-related) bug?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
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
UnresolvedPermission.resolve.
Cheers,
Peter.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
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
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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.... :]
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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() ?
Gr. Sim
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
On 11/21/2010 8:29 AM, Jonathan Costers wrote:
> 2010/11/21 Patricia Shanahan<pa...@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
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/11/21 Patricia Shanahan <pa...@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.
> Patricia
>
>
>
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@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.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
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 would probably have seen it once I started looking closely at the
permission checking, but that saves me some time.
My current guess is that something is being done as String manipulation
that should be done using API classes such as File, which knows about
the different path naming rules. However, I'll know better once I find
where that extra "/" is coming from.
Patricia
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Jonathan Costers <jo...@googlemail.com>.
2010/11/21 Peter Firmstone <ji...@zeus.net.au>
> 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)
>>
>>
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:
> 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.
>>
>>
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
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.
>
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
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.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
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
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
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.
>
> Peter.
>
I wonder if the policy file has a Permission grant with a bad path?
That might explain the missing permission.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Peter Firmstone <ji...@zeus.net.au>.
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.
Peter.
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Patricia Shanahan <pa...@acm.org>.
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
Re: Build failed in Hudson: River-trunk-QA-windows #7
Posted by Sim IJskes - QCG <si...@qcg.nl>.
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?
Gr. Sim