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
