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.
the resendes seems wrong, the ones starting with fs look right (although
a driveletter spec is missing).
Did we find a (non-related) bug?
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
