On 04/21/2015 10:48 AM, Sean Mullan wrote:
On 04/21/2015 01:36 PM, Mandy Chung wrote:
Good point.  They are all interfaces that don't require any permission.

Ah, ok. Never mind then.

I'm inclined to suggest the client, e.g. implementation classes,
requiring jdk.xml.dom should configure proper permissions for itself as
well as permissions required by jdk.xml.dom.

Yes, but that would require editing the policy file on systems which may not be under your control.


OK. I think it's better to follow up this after further discussion for the deprivileging work and understand what can or can't be done in editing the policy files. For now, we should keep existing behavior to grant jdk.xml.dom AllPermissions. How does that sound?

Joe - the file is in jdk/src/java.base/share/conf/security/java.policy.


Mandy

--Sean

Otherwise it would require
AllPermissions.


Mandy

On 04/21/2015 10:26 AM, Sean Mullan wrote:
Do we also need to change the java.policy file to grant specific
permissions to the jdk.xml.dom module?

--Sean

On 04/21/2015 01:19 PM, huizhe wang wrote:
Thanks Mandy, Alan.

Fixed the issues. Here's the updated webrev:
http://cr.openjdk.java.net/~joehw/jdk9/8078139/webrev/

-Joe

On 4/21/2015 10:10 AM, Alan Bateman wrote:
On 21/04/2015 17:54, huizhe wang wrote:
Hi,

By JDK-8042244, we moved several org.w3c.dom packages to a module
called jdk.xml.dom. This new module shall be loaded by the ext class
loader.  Please review the patch for the change.

http://cr.openjdk.java.net/~joehw/jdk9/8078139/webrev/
Looks okay. I assume @test is not needed in this test because it's a
TestNG tree, is that right?

-Alan



Reply via email to