Ok, let's document this clearly though. There may be users that have configuration to route logging from an inner class to a separate appender. If I'm not mistaken our change will break such configurations.
Also: does Class.getCanonicalName() preserve the trailing $ in Scala classes? (Shameless plug) Every java main() method deserves http://picocli.info > On Aug 20, 2017, at 15:43, Ralph Goers <[email protected]> wrote: > > And I doubt there are many use cases where doing that will be an issue. > > Ralph > >> On Aug 19, 2017, at 5:35 PM, Gary Gregory <[email protected]> wrote: >> >> The only change I am now talking about is replacing getName() with >> getCannonicalName(). >> >> Gary >> >>> On Aug 19, 2017 18:00, "Remko Popma" <[email protected]> wrote: >>> >>> No objection to creating logger names from Class.getCanonicalName() instead >>> of Class.getName(). I assume that this means we don't need a custom >>> toLoggerName(Class) >>> method. >>> >>> Question for our Scala experts: does Class.getCanonicalName() preserve the >>> trailing $ in Scala classes? >>> >>> At some point there was talk of API changes. Is that still needed? >>> Finally, I guess in order to keep supporting the current behaviour as well, >>> we still need to build configuration support for this <Configuration >>> hierarchySeparators="./$" ... Is my understanding correct? >>> >>> >>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers <[email protected]> >>> wrote: >>> >>>> I agree. >>>> >>>> Ralph >>>> >>>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker <[email protected]> wrote: >>>>> >>>>> Canonical name sounds like it makes sense. I wonder what that evaluates >>>> to >>>>> in other JVM languages like Scala, Kotlin, Clojure, etc., but it seems >>> to >>>>> make sense. >>>>> >>>>> On 19 August 2017 at 13:23, Dominik Psenner <[email protected]> >>> wrote: >>>>> >>>>>> To me it is a simple and good solution to the problem. The first >>>> outlined >>>>>> solution has the pro that it would give a user more sophisticated ways >>>> to >>>>>> build logger hierarchies from class names, but it is also something >>> that >>>>>> only a very small subset of users would use. We can keep that as a >>> wish >>>> for >>>>>> later. >>>>>> >>>>>> 2017-08-19 20:13 GMT+02:00 Gary Gregory <[email protected]>: >>>>>> >>>>>>> Any opposition to using the canonical name? >>>>>>> >>>>>>> Gary >>>>>>> >>>>>>> On Aug 14, 2017 15:28, "Gary Gregory" <[email protected]> >>> wrote: >>>>>>> >>>>>>>> In LogManager, if we call getCanonicalName() instead of getName(), >>> we >>>>>>> only >>>>>>>> get "."s, no "$"s... >>>>>>>> >>>>>>>> How about that? >>>>>>>> >>>>>>>> Gary >>>>>>>> >>>>>>>> On Mon, Aug 14, 2017 at 3:24 PM, Gary Gregory < >>> [email protected] >>>>> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Another way to look at this is that instead of calling >>>> class.getName() >>>>>>> we >>>>>>>>> would call our own toLoggerName(Class) which would NOT use $ but >>> only >>>>>>> use >>>>>>>>> "."s. >>>>>>>>> >>>>>>>>> Gary >>>>>>>>> >>>>>>>>> On Mon, Aug 14, 2017 at 3:07 PM, Matt Sicker <[email protected]> >>>>>> wrote: >>>>>>>>> >>>>>>>>>> The logger name hierarchy interpretation is handled at the string >>>>>>> level, >>>>>>>>>> not the class level. I don't think the class needs to be passed >>>> along >>>>>>> as >>>>>>>>>> there isn't much useful info we can get from the Class instance >>> that >>>>>> we >>>>>>>>>> can't already figure out from its FQCN. >>>>>>>>>> >>>>>>>>>> On 14 August 2017 at 15:56, Ralph Goers < >>> [email protected] >>>>> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> On Aug 14, 2017, at 1:38 PM, Gary Gregory < >>>>>> [email protected]> >>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers < >>>>>>>>>> [email protected] >>>>>>>>>>> <mailto:[email protected]>> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> On Aug 14, 2017, at 11:49 AM, Gary Gregory < >>>>>>> [email protected] >>>>>>>>>>> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory < >>>>>>>>>> [email protected] >>>>>>>>>>>> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Probably for Ralph: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Right now, it's the LogManager in log4j-api that converts >>>>>> Class >>>>>>>>>> names >>>>>>>>>>>>> into >>>>>>>>>>>>>>> Logger names. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> There is no getLogger(Class) API in the Core LoggerContext. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Should we push down this conversion into Core's >>> LoggerContext? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems the sane thing to do to: >>>>>>>>>>>>>>> - Avoid making something pluggable in log4j-api >>>>>>>>>>>>>>> - Avoid making Core parse logger names looking for >>> separators. >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> But that would mean adding two methods to: >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext: >>>>>>>>>>>>>> >>>>>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class< >>> ?>) >>>>>>>>>>>>>> org.apache.logging.log4j.spi.LoggerContext.getLogger(Class< >>> ?>, >>>>>>>>>>>>>> MessageFactory) >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thoughts? >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Why does it mean that? >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> If we want the core to implement converting Class names to >>> Logger >>>>>>>>>> names, >>>>>>>>>>>> the Class must be passed down to the Core. Right now the >>>>>> LogManager >>>>>>>>>> does >>>>>>>>>>>> that by calling org.apache.logging.log4j.spi.LoggerContext >>>>>>> methods. >>>>>>>>>>> These >>>>>>>>>>>> methods take only String for the logger name. >>>>>>>>>>> >>>>>>>>>>> And that is a problem because….? I am trying to understand why >>>>>>>>>>> LoggerContext will be required to accept a class name. >>>>>>>>>>> >>>>>>>>>>> Ralph >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Matt Sicker <[email protected]> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dominik Psenner >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Matt Sicker <[email protected]> >>>> >>>> >>>> >>> > >
