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

Mark Thomas markt at apache.org
Fri Jan 19 17:34:32 UTC 2018

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

More information about the core-libs-dev mailing list