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

[Jason Mehrens]

Daniel,

Looking at: https://github.com/apache/tomcat/blob/trunk/java/org/apache/juli/ClassLoaderLogManager.java it looks like code in "readConfiguration(InputStream, ClassLoader)" does the digit translation.
The tomcat developers should be able to move some of that code to CLLM.getProperty to do the translation.

If they don't want JUL to create the root handlers then another option would be to alter CLLM.getProperty to determine if the j.ul.LogManager is trying to initialize ".handers" before CLLM.readConfiguration is called and return null to effectively disable creating handlers at that time.  My guess is  that this change is probably more compatible with what was already happening in Tomcat.

Jason

________________________________________
From: core-libs-dev <core-libs-dev-bounces at openjdk.java.net> on behalf of Daniel Fuchs <daniel.fuchs at oracle.com>
Sent: Friday, January 19, 2018 8:22 AM
To: core-libs-dev
Subject: Re: [JDK 11] RFR: 8195096: Exception printed on console with custom LogManager on starting Apache Tomcat

Hi,

For the record, I updated the JBS issue [1] with Jason's suggestion
and asked to get feedback from the submitter.

best regards,

-- daniel
[1] https://bugs.openjdk.java.net/browse/JDK-8195096


On 19/01/2018 10:13, Daniel Fuchs wrote:
> 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
>