On 19/01/18 19:25, Daniel Fuchs wrote: > Hi Mark, > > Would it be possible for you to call super.getProperty() > when you want to see the 'raw' value, and > this.getProperty() when you want to see the 'corrected' > value?
Hi Daniel, I see where you are coming from but I don't think so. Jason made a suggestion off-list that got me thinking in slightly different direction. I'm going to look at whether I can use a ThreadLocal to indicate where the call originates so requests for ".handlers" are responded to differently for CLLM and LM. I'm not sure what is possible at this point. I need to do some more research. Thanks to both of you for the hints that have got me thinking in new directions for a workaround. Mark > > best regards, > > -- daniel > > On 19/01/2018 17:34, Mark Thomas wrote: >> 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
