Thanks Alan. Updates made and changes pushed.
regards,
Sean.
On 13/01/2020 18:50, Alan Bateman wrote:
On 13/01/2020 10:28, Seán Coffey wrote:
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place,
the EventHelper utility
On 13/01/2020 10:28, Seán Coffey wrote:
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place,
the EventHelper utility class should never initialize the logging
framework early during jar initialization.
http://cr.openjdk
On 13/01/2020 17:21, Chris Hegarty wrote:
On 13 Jan 2020, at 17:19, Seán Coffey wrote:
Thanks for the reviews. All callers of EventHelper log methods are ensuring
that isLoggingSecurity() is true before proceeding. I've added an assert null
check in the 4 logger methods to ensure expectations
> On 13 Jan 2020, at 17:19, Seán Coffey wrote:
>
> Thanks for the reviews. All callers of EventHelper log methods are ensuring
> that isLoggingSecurity() is true before proceeding. I've added an assert null
> check in the 4 logger methods to ensure expectations are in place.
>
> http://cr.o
Thanks for the reviews. All callers of EventHelper log methods are
ensuring that isLoggingSecurity() is true before proceeding. I've added
an assert null check in the 4 logger methods to ensure expectations are
in place.
http://cr.openjdk.java.net/~coffeys/webrev.8234466.v5/webrev/
Hope this
On 13/01/2020 14:06, Chris Hegarty wrote:
I’m going to ask, since I cannot find the answer myself. Why are some
securityLogger::log invocations guarded with isLoggingSecurity, and others not?
With this change shouldn’t all invocations be guarded, since it is
isLoggingSecurity that assigns secu
> On 13 Jan 2020, at 13:14, Daniel Fuchs wrote:
>
> On 13/01/2020 10:28, Seán Coffey wrote:
>> some off line comments suggested that I could move the jar initialization
>> checks to the EventHelper class. With that in place, the EventHelper utility
>> class should never initialize the loggin
On 13/01/2020 10:28, Seán Coffey wrote:
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place, the
EventHelper utility class should never initialize the logging framework
early during jar initialization.
http://cr.openjdk
some off line comments suggested that I could move the jar
initialization checks to the EventHelper class. With that in place, the
EventHelper utility class should never initialize the logging framework
early during jar initialization.
http://cr.openjdk.java.net/~coffeys/webrev.8234466.v4/webr
The recent crypto event logging mechanism (JDK-8148188) has introduced a
regression whereby the System Logger may be invoked too early in the
bootstrap phase. This causes issue when JarFile objects are locked by
JarFile verifier initialization code. The logging work records an X509
Certificate
10 matches
Mail list logo
