On 05/01/2015 12:33 PM, Mandy Chung wrote:
On 05/01/2015 05:48 AM, Sean Mullan wrote:
Please review this change to use the system class loader to locate a
policy provider specified with the policy.provider security property.
The current implementation tries to load the provider using the
extension class loader. This will no longer work when the extension
mechanism is removed, which is proposed as part of JEP 220:
http://openjdk.java.net/jeps/220
webrev: http://cr.openjdk.java.net/~mullan/webrevs/8075706/webrev.01/
Looks okay.
Nit: line 208-209 - this is rather hard to read. probably worth some
cleanup/adjustment.
I thought about that, but I think it's best if that code is left as-is
for now. It is already bumping up against the 80 char limit, so I would
have to refactor that into another method but there are some subtle
concurrency issues, so I would prefer not to break up the code just to
do that. I'll look at this again later as part of another bug.
CustomPolicy.implies
50 if (pd == policyPd) {
51 return true;
52 }
This is okay for the test. Just for my understanding, for real world
custom policy, should it check the code source in case the sensitive
operation triggering a permission check involving other classes?
Permissions are granted per ProtectionDomain (PD) so this is sufficient.
However, typically the policy provider would be in a separate PD from
other code (for example, by packaging it in a separate JAR file), but
this is sufficient for testing purposes. If you remove the lines above
from the test, you will get a StackOverflowError.
Thanks,
Sean
