On 11/22/2010 7:22 AM, Sim IJskes - QCG wrote:
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.
Yes, i hadn't forgotten, but is it a bug or intentional.
The second one is a relative url, the first one isn't.
When we look at the javadocs for SharedActivationPolicyPermission the
policy string argument has the same semantics as FilePermission.
FilePermission has no URL, so SharedActivationPolicyPermission should
not be a URL.
Flawed reasoning? Either the testcases with URL were undetected bugs, or
the javadoc for SharedActivationPolicyPermission is a bug.
The URL stuff in init() is just enlisted to do some FileSeparator
conversion, if the javadoc is right.
Gr. Sim
P.S. Bob? Any change that little birdie you talked about will tell us
the solution?
I think I understand what you are saying, but I'm not 100% sure, so I'm
going to repeat back the message I'm getting:
The implementation of SharedActivationPolicyPermission depends on
FilePermission. Its Javadoc comment requires a policy string argument
that conforms to the FilePermission policy string semantics.
A URL, in general, is not a valid FilePermission policy string. On the
other hand, a File path is. Incidentally, I've tested handling of the
FilePermission wildcards in the File class, and it all works.
File can do the "/" conversion correctly and automatically for the
system on which it is run. Doing the conversion on the file path portion
of the URL makes the test case I've been working on pass on both Windows
and Ubuntu.
Even if we make no change in the actual interface,
SharedActivationPolicyPermission should enforce its stated requirement
that the policy string constructor argument conform to FilePermssion
policy semantics.
After looking at all this, I'm thinking in terms of pushing the problem
up a layer, and requiring a File argument instead of a String. That
makes the idea of local File'ness explicit.
There is only one use of SharedActivationPolicyPermission in the River
production code, in ActivateWrapper. The remaining calls are all tests
which we can modify or drop as appropriate. I'm inclined to the view
that a test that passes a string that does not conform to FilePermission
policy string semantics should expect an IllegalArgumentException from
the constructor.
Patricia
