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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > wrote: > >> > >> The only change I am now talking about is replacing getName() with > >> getCannonicalName(). > >> > >> Gary > >> > >>> On Aug 19, 2017 18:00, "Remko Popma" <[email protected]> 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 < > [email protected]> > >>> wrote: > >>> > >>>> I agree. > >>>> > >>>> Ralph > >>>> > >>>>> On Aug 19, 2017, at 11:43 AM, Matt Sicker <[email protected]> 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 <[email protected]> > >>> 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 <[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 > >>>>>> > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Matt Sicker <[email protected]> > >>>> > >>>> > >>>> > >>> > > > > > -- Matt Sicker <[email protected]>
