[JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat (original) (raw)

Jason Mehrens jason_mehrens at hotmail.com
Fri Jan 19 16:51:57 UTC 2018

Daniel,

Double check me on this but, I think I've found the source of why the error occurs on JDK9 and not JDK8. In https://bugs.openjdk.java.net/browse/JDK-8191033 the new code should have been added to initializeGlobalHandlers. That would make the read of ".handers" lazy and keep the read of "handlers" eager.

Jason

From: Daniel Fuchs <daniel.fuchs at oracle.com> Sent: Friday, January 19, 2018 4:13 AM To: Jason Mehrens; core-libs-dev Subject: Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Hi Jason,

On 18/01/2018 21:19, Jason Mehrens wrote:

Daniel,

As long as the org.apache.juli.ClassLoaderLogManager overrides getProperty it shouldn't really matter what the value format is in the file as long as it is translated on return. Is there a code path in j.u.l.LogManager that doesn't call getProperty? If so I would think that is the core issue.

That's a very good question. Why didn't I think of it?

AFAICS there's only one place where we do that, in the 'new' updateConfiguration method, and that's only for levels when a level value is changed by the mapper callback (the new value is used directly without invoking getProperty). Maybe I should log a bug to fix that, but then that's probably not a big issue as it's returned by the mapper.

However in the case at hand the private createLoggerHandler method eventually does calls LogManager.getProperty(".handlers"). In the base LogManager that should be the only place where LogManager.getProperty(".handlers") is called - I think.

Hmmm... I assume that might also depend on whether other classes call org.apache.juli.ClassLoaderLogManager::getProperty(".handlers") from outside, but then maybe that can be worked around in Tomcat as well.

Let me try if I can get feedback on this suggestion.

best regards,

-- daniel

Jason

More information about the core-libs-dev mailing list