Hi Mandy, Daniel,
Thanks for reviews. I just pushed this change to jdk9-dev/jdk ...
Regards, Peter
On 12/23/2013 05:50 AM, Mandy Chung wrote:
On 12/22/2013 5:23 AM, Peter Levart wrote:
Hi Mandy,
On 12/19/2013 10:38 PM, Mandy Chung wrote:
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy,
On 12/22/2013 5:23 AM, Peter Levart wrote:
Hi Mandy,
On 12/19/2013 10:38 PM, Mandy Chung wrote:
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy, Daniel,
I didn't like the package-protected getters either. So here's
another variant that replaces Handler.configure() method with a
package-p
Hi Mandy,
On 12/19/2013 10:38 PM, Mandy Chung wrote:
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy, Daniel,
I didn't like the package-protected getters either. So here's another
variant that replaces Handler.configure() method with a
package-protected constructor which is chained from JD
On 12/19/13 7:49 AM, Peter Levart wrote:
Hi Mandy, Daniel,
I didn't like the package-protected getters either. So here's another
variant that replaces Handler.configure() method with a
package-protected constructor which is chained from JDK subclasses:
http://cr.openjdk.java.net/~plevart/jdk
Hi Peter,
Good idea to add a package constructor in Handler.
It looks much cleaner than the configure method.
Good tests too - thanks for adding that!
To access files with JPRT there is a simpler manner (though what
you have looks good).
JPRT sets a system property "test.src" which point at the
On 12/18/2013 11:55 PM, Mandy Chung wrote:
On 12/18/2013 9:03 AM, Peter Levart wrote:
Hi Mandy, Daniel,
Here's yet another variant that reduces the doPrivileged code to just
Handler's setters. This way no LogManager methods are invoked under
elevated privilege:
http://cr.openjdk.java.net/~
On 14/12/2013 11:25, Peter Levart wrote:
It's unfortunate that a lambda debugging feature prevents us from
using a basic language feature in j.u.logging code. As far as I know,
java.lang.invoke.ProxyClassesDumper is only used if
'jdk.internal.lambda.dumpProxyClasses' system property is set to
On 12/18/2013 9:03 AM, Peter Levart wrote:
Hi Mandy, Daniel,
Here's yet another variant that reduces the doPrivileged code to just
Handler's setters. This way no LogManager methods are invoked under
elevated privilege:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.06
On 12/18/2013 5:55 AM, Peter Levart wrote:
On 12/17/2013 06:43 PM, Mandy Chung wrote:
Can you check what methods are called by the constructors whose
access are denied in the current implementation but granted in the
patch? I have to take another look to make sure but I believe they
only cal
On 12/17/2013 06:43 PM, Mandy Chung wrote:
Can you check what methods are called by the constructors whose access
are denied in the current implementation but granted in the patch? I
have to take another look to make sure but I believe they only calls
the methods in the handler classes that ca
On 12/17/2013 06:43 PM, Mandy Chung wrote:
Can you check what methods are called by the constructors whose access
are denied in the current implementation but granted in the patch? I
have to take another look to make sure but I believe they only calls
the methods in the handler classes that ca
On 12/18/2013 12:05 PM, Daniel Fuchs wrote:
But then we have another problem with doPrivileged approach, since it is
even more restrictive than 'sealed' field approach. Currently the
Handler's subclass that overrides a setter and calls super, works:
@Override
public void setOutputStream(OutputS
methods? For
example,
@Override
public void setOutputStream(OutputStream out) {
LogManager.getLogManager().reset();
}
@Override
public void setLevel(Level l) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.ch...@oracle.com
&g
oid setOutputStream(OutputStream out) {
LogManager.getLogManager().reset();
}
@Override
public void setLevel(Level l) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.ch...@oracle.com
> To: peter.lev...@gmail.com
> Subjec
m(OutputStream out) {
LogManager.getLogManager().reset();
}
@Override
public void setLevel(Level l) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.ch...@oracle.com
> To: peter.lev...@gmail.com
> Subject: Re: Theoretic
invoking non-final public/protected methods? For
example,
@Override
public void setOutputStream(OutputStream out) {
LogManager.getLogManager().reset();
}
@Override
public void setLevel(Level l) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0
mple,
@Override
public void setOutputStream(OutputStream out) {
LogManager.getLogManager().reset();
}
@Override
public void setLevel(Level l) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.ch...@oracle.com
> To: peter.l
; From: mandy.ch...@oracle.com
> To: peter.lev...@gmail.com
> Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> CC: core-libs-dev@openjdk.java.net
>
> On 12/14/2013 9:38 AM, Peter Levart wrote:
> > Hi,
> >
> > Daniel reminded me of a couple of issues th
@gmail.com
> Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> CC: core-libs-dev@openjdk.java.net
>
> On 12/14/2013 9:38 AM, Peter Levart wrote:
> > Hi,
> >
> > Daniel reminded me of a couple of issues the 4th revision of the
patch
> > would
On 12/17/2013 11:29 AM, Daniel Fuchs wrote:
On 12/16/13 10:14 PM, Mandy Chung wrote:
On 12/14/2013 9:38 AM, Peter Levart wrote:
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that
tries to be more backport
) {
LogManager.getLogManager().reset();
}
Jason
> Date: Mon, 16 Dec 2013 13:14:03 -0800
> From: mandy.ch...@oracle.com
> To: peter.lev...@gmail.com
> Subject: Re: Theoretical data race on java.util.logging.Handler.sealed
> CC: core-libs-dev@openjdk.java.net
>
> On 12/14/2013 9:38 A
On 12/16/13 10:14 PM, Mandy Chung wrote:
On 12/14/2013 9:38 AM, Peter Levart wrote:
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that
tries to be more backport-friendly:
http://cr.openjdk.java.net/~pleva
On 12/14/2013 9:38 AM, Peter Levart wrote:
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that
tries to be more backport-friendly:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05
On 12/14/13 6:38 PM, Peter Levart wrote:
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that tries
to be more backport-friendly:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
Th
Hi,
Daniel reminded me of a couple of issues the 4th revision of the patch
would have when backporting to 7u. So here's another variant that tries
to be more backport-friendly:
http://cr.openjdk.java.net/~plevart/jdk8-tl/jul.Handler.sealed/webrev.05/
This variant could be backported by simpl
Hi Mandy,
On 12/13/2013 12:37 AM, Mandy Chung wrote:
Hi Peter,
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variabl
Hi Peter,
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
i
On 12/10/2013 12:48 AM, Alan Bateman wrote:
On 10/12/2013 04:13, Mandy Chung wrote:
On 12/8/2013 11:19 AM, Peter Levart wrote:
:
You're right, doPrivileged() is a more straight-forward approach
than 'sealed' variable. Since this might only be considered for
inclusion in JDK9 when lambdas
On 10/12/2013 04:13, Mandy Chung wrote:
On 12/8/2013 11:19 AM, Peter Levart wrote:
:
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
in JDK9 when lambdas are already a tried technology, how do you fee
On 12/8/2013 11:19 AM, Peter Levart wrote:
H Mandy,
I created an issue for it nevertheless:
https://bugs.openjdk.java.net/browse/JDK-8029781
You're right, doPrivileged() is a more straight-forward approach than
'sealed' variable. Since this might only be considered for inclusion
in JDK9 wh
Hi Peter,
I had a look at your later webrev 03 and it looks like a good
solution to fix the issue. I am glad to see the sealed
variable removed.
About using lambda I don't know whether we have guidelines
for that - in this case it certainly makes the code more
concise. It is good to remember tha
On 12/04/2013 12:27 AM, Mandy Chung wrote:
On 12/3/2013 1:44 AM, Peter Levart wrote:
On 12/03/2013 09:51 AM, Peter Levart wrote:
Hi,
While browsing the code of java.util.logging.Handler, I noticed a
theoretical possibility that a security check in a
j.u.l.StreamHandler be circumvented usin
On 12/3/2013 1:44 AM, Peter Levart wrote:
On 12/03/2013 09:51 AM, Peter Levart wrote:
Hi,
While browsing the code of java.util.logging.Handler, I noticed a
theoretical possibility that a security check in a
j.u.l.StreamHandler be circumvented using a data race.
There is a plain boolean ins
On 12/03/2013 09:51 AM, Peter Levart wrote:
Hi,
While browsing the code of java.util.logging.Handler, I noticed a
theoretical possibility that a security check in a j.u.l.StreamHandler
be circumvented using a data race.
There is a plain boolean instance field 'sealed' in j.u.l.Handler that
Hi,
While browsing the code of java.util.logging.Handler, I noticed a
theoretical possibility that a security check in a j.u.l.StreamHandler
be circumvented using a data race.
There is a plain boolean instance field 'sealed' in j.u.l.Handler that
is pre-initialized to 'true' in field initial
35 matches
Mail list logo
