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>
