2010/11/21 Peter Firmstone <j...@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. >> >> >
