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

[Mark Thomas]

On 19/01/18 14:22, Daniel Fuchs wrote:
> Hi,
> 
> For the record, I updated the JBS issue [1] with Jason's suggestion
> and asked to get feedback from the submitter.

Providing feedback, as requested.

Thanks for looking at this so quickly. The speedy response is appreciated.

I did look to try and handle this in getProperty() but I ran into the
following problem.

ClassLoaderLogManager expects getProperty() to return the custom value
for .handlers that includes the modified class name. If this value is
returned, LogManager generates the unwanted stack trace. If the value is
'corrected' so LogManager doesn't generate the stack trace,
ClassLoaderLogManager sees the wrong value and isn't configured correctly.

If I've missed a way to handle this, a pointer to that solution is
appreciated. I spent some time looking at a way to work around it before
raising a bug and I couldn't find a practical solution. I really didn't
want to start down the road of looking at the call stack to determine
how to handle values in getProperty().

The protected addInitialRootLoggerHandlers() solution looks to be
exactly what is required.

Kind regards,

Mark


> 
> 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  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
>>
>