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

[Daniel Fuchs]

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
>