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 <[email protected]>: > Any opposition to using the canonical name? > > Gary > > On Aug 14, 2017 15:28, "Gary Gregory" <[email protected]> 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 <[email protected]> > > 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 <[email protected]> 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 <[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]> > >>> > >> > >> > > > -- Dominik Psenner
