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/


Reply via email to