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

Daniel Fuchs daniel.fuchs at oracle.com
Fri Jan 19 14:22:48 UTC 2018


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

More information about the core-libs-dev mailing list