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>
