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
