It turns out that I have some use cases for the Core LoggerContext to support getLogger(Class<?>), which is really a convenience to avoid calling Class.getName() but then I am in the same pickle.
That tells me that: - either Core needs to parse logger names and do char subst. - or Core LoggerContext should support getLogger(Class<?>) Gary On Mon, Aug 14, 2017 at 12:49 PM, 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? > > Gary > > > >> Gary >> >> >> On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner <[email protected]> >> wrote: >> >>> I wrote this up in a jira issue at [1]. Unfortunately I'm struggling with >>> my health and I can't give an estimate of when I can work on this. If you >>> want it for the next release, please take over the work right away as I >>> won't be able to contribute further. >>> >>> [1] https://issues.apache.org/jira/browse/LOG4J2-2010 >>> >>> 2017-08-14 1:14 GMT+02:00 Gary Gregory <[email protected]>: >>> >>> > Recapping: >>> > >>> > Using it: >>> > >>> > <Configuration hierarchySeparators="./$" ... >>> > >>> > Default: >>> > >>> > <Configuration hierarchySeparators="." ... >>> > >>> > Dominik: Do you want to take a shot at it? >>> > >>> > Gary >>> > >>> > >>> > >>> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers < >>> [email protected]> >>> > wrote: >>> > >>> > > Yes, that is the way I would envision it. The default would be how it >>> > > works now. >>> > > >>> > > Ralph >>> > > >>> > > > On Aug 13, 2017, at 12:37 PM, Gary Gregory <[email protected] >>> > >>> > > wrote: >>> > > > >>> > > > Well we can make an exception for trailing $? >>> > > > >>> > > > Do we want to add an attribute in the Configuration XML element? >>> For >>> > > > example hierarchySeparators=".$/" >>> > > > >>> > > > What should the default be? >>> > > > >>> > > > Gary >>> > > > >>> > > > On Aug 13, 2017 12:17, "Matt Sicker" <[email protected]> wrote: >>> > > > >>> > > >> Having the dollar sign interpreted differently also makes a >>> difference >>> > > in >>> > > >> Scala classes and potentially other languages. For example, in >>> Scala, >>> > an >>> > > >> "object" class is a singleton instance of the class (vaguely >>> similar >>> > to >>> > > a >>> > > >> class with all static methods and fields), and it's translated to >>> a >>> > Java >>> > > >> class name with a dollar sign appended. The Scala code "object >>> Foo { >>> > > ... }" >>> > > >> translates to the equivalent of "public class Foo$ { public static >>> > Foo$ >>> > > >> MODULE$ = new Foo$(); ... }" or something like that. >>> > > >> >>> > > >> On 13 August 2017 at 11:08, Apache <[email protected]> >>> > wrote: >>> > > >> >>> > > >>> You cannot replace. We always must support dots. But some people >>> have >>> > > >>> asked for '/' as well. >>> > > >>> >>> > > >>> Sent from my iPad >>> > > >>> >>> > > >>>> On Aug 13, 2017, at 8:38 AM, Dominik Psenner < >>> [email protected]> >>> > > >> wrote: >>> > > >>>> >>> > > >>>> Yes >>> > > >>>> >>> > > >>>>> On 13 Aug 2017 5:13 p.m., "Gary Gregory" < >>> [email protected]> >>> > > >>> wrote: >>> > > >>>>> >>> > > >>>>> You are talking about replacing $ with dot in the >>> getLogger(Class) >>> > > >> API? >>> > > >>>>> >>> > > >>>>> Gary >>> > > >>>>> >>> > > >>>>>> On Aug 13, 2017 01:57, "Dominik Psenner" <[email protected]> >>> > > wrote: >>> > > >>>>>> >>> > > >>>>>> Could the $ be replaced by a dot when the logger is >>> instantiated? >>> > > >>> Log4net >>> > > >>>>>> picks the class name as logger name but also allows custom >>> logger >>> > > >>> names. >>> > > >>>>>> >>> > > >>>>>> On 13 Aug 2017 8:30 a.m., "Ralph Goers" < >>> > [email protected] >>> > > > >>> > > >>>>>> wrote: >>> > > >>>>>> >>> > > >>>>>>> Rather than implementing this I would rather have the >>> separator >>> > > >> chars >>> > > >>>>> be >>> > > >>>>>>> specifiable in the configuration. Blatantly making this >>> change >>> > > might >>> > > >>>>>> cause >>> > > >>>>>>> compatibility problems, although I am not really sure how it >>> > could. >>> > > >>>>>>> >>> > > >>>>>>> Ralph >>> > > >>>>>>> >>> > > >>>>>>>> On Aug 12, 2017, at 11:29 AM, Gary Gregory < >>> > > [email protected] >>> > > >>> >>> > > >>>>>>> wrote: >>> > > >>>>>>>> >>> > > >>>>>>>> Hi All, >>> > > >>>>>>>> >>> > > >>>>>>>> I you use nested classes to build loggers, you end up with >>> > logger >>> > > >>>>> names >>> > > >>>>>>>> like A$N1, A$N2 and so on. >>> > > >>>>>>>> >>> > > >>>>>>>> If you then set a logger level in a config using "A", it >>> does >>> > not >>> > > >>>>>> affect >>> > > >>>>>>>> A$N1 and A$N2 as you might expect, since "$" is not a ".". >>> > > >>>>>>>> >>> > > >>>>>>>> What about treating "$" like a "."? >>> > > >>>>>>>> >>> > > >>>>>>>> Thoughts? >>> > > >>>>>>>> >>> > > >>>>>>>> Gary >>> > > >>>>>>> >>> > > >>>>>>> >>> > > >>>>>>> >>> > > >>>>>> >>> > > >>>>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > > >> >>> > > >> >>> > > >> -- >>> > > >> Matt Sicker <[email protected]> >>> > > >> >>> > > >>> > > >>> > > >>> > >>> >>> >>> >>> -- >>> Dominik Psenner >>> >> >> >
