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.
