On Mon, 2019-07-22 at 12:06 +0100, Alan Bateman wrote:
> On 22/07/2019 10:12, Severin Gehwolf wrote:
> > :
> > Take 03:
> > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/
> >
> > This now reverts Platform.java changes to the version prior JDK-
> > 8227642, introduces a Contain
On 22/07/2019 10:12, Severin Gehwolf wrote:
:
Take 03:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/
This now reverts Platform.java changes to the version prior JDK-
8227642, introduces a Container class with one constant,
CONTAINER_ENGINE, and renames the jdk.test.docker.c
Hi Mandy,
On Fri, 2019-07-19 at 10:32 -0700, Mandy Chung wrote:
> I still think separating container-specific APIs in its own class will
> prevent running similar kind of issue in the future.
Take 03:
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/03/webrev/
This now reverts Platform.
> On Jul 19, 2019, at 12:44 PM, Alan Bateman wrote:
>
> On 19/07/2019 18:59, Igor Ignatyev wrote:
>> haven't we identified and *fixed* all the tests which use j.t.l.Platform
>> class and their own security policy (as part of 8210039 or other testlibrary
>> refactoring)? in other words, all th
On 19/07/2019 18:59, Igor Ignatyev wrote:
haven't we identified and *fixed* all the tests which use j.t.l.Platform class
and their own security policy (as part of 8210039 or other testlibrary
refactoring)? in other words, all the tests which use j.t.l.Platform must have
a policy file which gra
haven't we identified and *fixed* all the tests which use j.t.l.Platform class
and their own security policy (as part of 8210039 or other testlibrary
refactoring)? in other words, all the tests which use j.t.l.Platform must have
a policy file which grants Platform java.util.PropertyPermission re
On 7/19/19 10:13 AM, Severin Gehwolf wrote:
Hi Mandy,
On Fri, 2019-07-19 at 09:58 -0700, Mandy Chung wrote:
Hi Severin,
On 7/19/19 9:55 AM, Severin Gehwolf wrote:
There might be other tests with policy files where this is not the case.
My issue is with finding those tests :-/ If we know t
Hi Mandy,
On Fri, 2019-07-19 at 09:58 -0700, Mandy Chung wrote:
> Hi Severin,
>
> On 7/19/19 9:55 AM, Severin Gehwolf wrote:
> > > There might be other tests with policy files where this is not the case.
> > My issue is with finding those tests :-/ If we know the set of *all*
> > tests affected b
On 19/07/2019 17:55, Severin Gehwolf wrote:
:
My issue is with finding those tests :-/ If we know the set of *all*
tests affected by the breakage we could do approach 2. Approach 1 (or
3) seems safer.
Any impact will be limited to tests using the test infrastructure but
using their own policy. I
Hi Severin,
On 7/19/19 9:55 AM, Severin Gehwolf wrote:
There might be other tests with policy files where this is not the case.
My issue is with finding those tests :-/ If we know the set of *all*
tests affected by the breakage we could do approach 2. Approach 1 (or
3) seems safer.
Severin -
On Fri, 2019-07-19 at 17:40 +0100, Alan Bateman wrote:
> On 19/07/2019 16:21, Claes Redestad wrote:
> > On 2019-07-19 17:07, Severin Gehwolf wrote:
> > > Do you have objections, to go with that, Claes?
> > >
> > > http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/
> >
> > While I
On 7/19/19 7:14 AM, Alan Bateman wrote:
On 19/07/2019 15:00, Severin Gehwolf wrote:
:
Sure. By adding a method also accepting a default value it would work
as well. If that's preferred, I can change it:
diff --git a/test/lib/jdk/test/lib/Platform.java
b/test/lib/jdk/test/lib/Platform.java
On 19/07/2019 16:21, Claes Redestad wrote:
On 2019-07-19 17:07, Severin Gehwolf wrote:
Do you have objections, to go with that, Claes?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/
While I think the privilegedGetProperty alternative would work just
fine regardless of sec
On 2019-07-19 17:07, Severin Gehwolf wrote:
Do you have objections, to go with that, Claes?
http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-8228434/01/webrev/
While I think the privilegedGetProperty alternative would work just
fine regardless of security settings, I don't object to this if yo
Hi Alan, Claes,
Shouldn't we consider the less risky alternative? I.e. the original webrev?
More below.
On Fri, 2019-07-19 at 15:14 +0100, Alan Bateman wrote:
>
> On 19/07/2019 15:00, Severin Gehwolf wrote:
> > :
> > Sure. By adding a method also accepting a default value it would work
> > as w
On 19/07/2019 15:00, Severin Gehwolf wrote:
:
Sure. By adding a method also accepting a default value it would work
as well. If that's preferred, I can change it:
diff --git a/test/lib/jdk/test/lib/Platform.java
b/test/lib/jdk/test/lib/Platform.java
--- a/test/lib/jdk/test/lib/Platform.java
Hi Claes,
On Fri, 2019-07-19 at 15:44 +0200, Claes Redestad wrote:
> Hi,
>
> why not just use the Platform.privilegedGetProperty method, which seems
> purpose built for avoiding issues with reading properties like these
> in tests running with a security manager?
Sure. By adding a method also ac
Hi,
why not just use the Platform.privilegedGetProperty method, which seems
purpose built for avoiding issues with reading properties like these
in tests running with a security manager?
/Claes
On 2019-07-19 15:40, Severin Gehwolf wrote:
Hi,
Please review this fix for an issue introduced by J
Hi,
Please review this fix for an issue introduced by JDK-8227642 pointed
out by Alan Bateman. Thanks, Alan! That enhancement introduced a new
constant in the test libraries' Platform class which can cause issues
in tests which run with a security manager. One such instance is
jdk/net/Sockets/Test
19 matches
Mail list logo
