In git master now tracked with LOG4J2-2023. Gary
On Mon, Aug 21, 2017 at 8:32 AM, Matt Sicker <boa...@gmail.com> wrote: > Calling getnCanonicalName on the Scala companion object preserves the > trailing $ as it's part of the class name itself. Thus: > > object Foo > println(Foo.getClass.getCanonicalName) > > Prints out "Foo$". More complete example (using ammonite, a Scala repl > thing): > > $ amm > Loading... > Welcome to the Ammonite Repl 1.0.1 > (Scala 2.12.3 Java 1.8.0_144) > If you like Ammonite, please support our development at > www.patreon.com/lihaoyi > @ object Foo > defined object Foo > > @ Foo.getClass.getCanonicalName > res1: String = "ammonite.$sess.cmd0.Foo$" > > So, go ahead with using getCanonicalName from the Scala point of view. > Groovy follows the same semantics for class naming as Java normally, so > that should work fine. I'd imagine Kotlin does similarly. I'm not sure > about Clojure, but they're already used to weird class naming schemes > compared to Java (e.g., using slashes instead of dots for > packages/namespaces). > > On 20 August 2017 at 23:49, Remko Popma <remko.po...@gmail.com> wrote: > > > Ok, let's document this clearly though. > > > > There may be users that have configuration to route logging from an inner > > class to a separate appender. If I'm not mistaken our change will break > > such configurations. > > > > Also: does Class.getCanonicalName() preserve the trailing $ in Scala > > classes? > > > > (Shameless plug) Every java main() method deserves http://picocli.info > > > > > On Aug 20, 2017, at 15:43, Ralph Goers <ralph.go...@dslextreme.com> > > wrote: > > > > > > And I doubt there are many use cases where doing that will be an issue. > > > > > > Ralph > > > > > >> On Aug 19, 2017, at 5:35 PM, Gary Gregory <garydgreg...@gmail.com> > > wrote: > > >> > > >> The only change I am now talking about is replacing getName() with > > >> getCannonicalName(). > > >> > > >> Gary > > >> > > >>> On Aug 19, 2017 18:00, "Remko Popma" <remko.po...@gmail.com> wrote: > > >>> > > >>> No objection to creating logger names from Class.getCanonicalName() > > instead > > >>> of Class.getName(). I assume that this means we don't need a custom > > >>> toLoggerName(Class) > > >>> method. > > >>> > > >>> Question for our Scala experts: does Class.getCanonicalName() > preserve > > the > > >>> trailing $ in Scala classes? > > >>> > > >>> At some point there was talk of API changes. Is that still needed? > > >>> Finally, I guess in order to keep supporting the current behaviour as > > well, > > >>> we still need to build configuration support for this <Configuration > > >>> hierarchySeparators="./$" ... Is my understanding correct? > > >>> > > >>> > > >>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers < > > ralph.go...@dslextreme.com> > > >>> wrote: > > >>> > > >>>> I agree. > > >>>> > > >>>> Ralph > > >>>> > > >>>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker <boa...@gmail.com> > wrote: > > >>>>> > > >>>>> 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> > > >>>> > > >>>> > > >>>> > > >>> > > > > > > > > > > > > -- > Matt Sicker <boa...@gmail.com> >
