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
