> 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
