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 <garydgreg...@gmail.com> wrote: > > The only change I am now talking about is replacing getName() with > getCannonicalName(). > > Gary > > On Aug 19, 2017 18:00, "Remko Popma" <remko.po...@gmail.com> 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 <ralph.go...@dslextreme.com> >> wrote: >> >>> I agree. >>> >>> Ralph >>> >>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker <boa...@gmail.com> 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 <dpsen...@gmail.com> >> 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 <garydgreg...@gmail.com>: >>>>> >>>>>> Any opposition to using the canonical name? >>>>>> >>>>>> Gary >>>>>> >>>>>> On Aug 14, 2017 15:28, "Gary Gregory" <garydgreg...@gmail.com> >> 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 < >> garydgreg...@gmail.com >>>> >>>>>>> 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 <boa...@gmail.com> >>>>> 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 < >> ralph.go...@dslextreme.com >>>> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Aug 14, 2017, at 1:38 PM, Gary Gregory < >>>>> garydgreg...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers < >>>>>>>>> ralph.go...@dslextreme.com >>>>>>>>>> <mailto:ralph.go...@dslextreme.com>> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Aug 14, 2017, at 11:49 AM, Gary Gregory < >>>>>> garydgreg...@gmail.com >>>>>>>>>> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory < >>>>>>>>> garydgreg...@gmail.com >>>>>>>>>>> >>>>>>>>>>>>> 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 <boa...@gmail.com> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Dominik Psenner >>>>> >>>> >>>> >>>> >>>> -- >>>> Matt Sicker <boa...@gmail.com> >>> >>> >>> >>
