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
