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]>
