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.java.net/~coffeys/webrev.8234466.v4/webrev/
Looks good to me Seán. Probably safer than the other alternatives.
46 private static boolean loggingSecurity;
that should be volatile too.
best regard,
-- daniel
regards,
Sean.
On 16/12/2019 14:15, Seán Coffey wrote:
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 which is used during the jar file
verification/initialization phase and hence leads to an early
System.Logger call.
One thread invokes the initialization of the Logger framework via
ServiceLoader and waits to lock a JarFile in use via another thread.
Unfortunately that other thread is also waiting for the System Logger
to initialize. For now, I think we can avoid the early Logger
initialization via use of a ThreadLocal. I've tried reproducing the
reported issue through manual and automated tests but to no avail.
I've added a new ServiceLoader test which has concurrent threads. One
is loading providers and another is initializing JarFile verifiers.
Hope it helps improve code coverage for the future.
JBS record: https://bugs.openjdk.java.net/browse/JDK-8234466
webrev : http://cr.openjdk.java.net/~coffeys/webrev.8234466/webrev/
