Re: Logger names for nested classes

In git master now tracked with LOG4J2-2023. Gary On Mon, Aug 21, 2017 at 8:32 AM, Matt Sicker 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) > > Prin

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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? (Shamel

Re: Logger names for nested classes

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 wrote: > > The only change I am now talking about is replacing getName() with > getCannonicalName(). > > Gary > > On Aug 19, 2017 18:00, "Remko Popma" wrote: > >> No obj

Re: Logger names for nested classes

The only change I am now talking about is replacing getName() with getCannonicalName(). Gary On Aug 19, 2017 18:00, "Remko Popma" 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 > toLogger

Re: Logger names for nested classes

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 w

Re: Logger names for nested classes

I agree. Ralph > On Aug 19, 2017, at 11:43 AM, Matt Sicker 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 wrote: >

Re: Logger names for nested classes

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 wrote: > To me it is a simple and good solution to the problem. The first outlined > soluti

Re: Logger names for nested classes

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 la

Re: Logger names for nested classes

Any opposition to using the canonical name? Gary On Aug 14, 2017 15:28, "Gary Gregory" 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 > wrote: > >> Another

Re: Logger names for nested classes

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 wrote: > Another way to look at this is that instead of calling class.getName() we > would call our own toLoggerName(Class) which w

Re: Logger names for nested classes

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 wrote: > The logger name hierarchy interpretation is handled at the string level, > not the

Re: Logger names for nested classes

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

Re: Logger names for nested classes

> On Aug 14, 2017, at 1:38 PM, Gary Gregory wrote: > > On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers > > wrote: > >> >>> On Aug 14, 2017, at 11:49 AM, Gary Gregory >> wrote: >>> >>> On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory >>> wrote: >>> Probab

Re: Logger names for nested classes

On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers wrote: > > > On Aug 14, 2017, at 11:49 AM, Gary Gregory > wrote: > > > > On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory > > wrote: > > > >> Probably for Ralph: > >> > >> Right now, it's the LogManager in log4j-api that converts Class names > into > >

Re: Logger names for nested classes

> On Aug 14, 2017, at 11:49 AM, Gary Gregory wrote: > > On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory > 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 Logger

Re: Logger names for nested classes

Thanks Gary! I've been struggling with this since half a year now. Unfortunately I even wasn't able to go to work since two months and it looks like this is not something that simply goes away over time. At this very moment I'm happy to be able to stand up straight, walk or even just sit and play

Re: Logger names for nested classes

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

Re: Logger names for nested classes

On Mon, Aug 14, 2017 at 12:35 PM, Gary Gregory 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 LoggerCont

Re: Logger names for nested classes

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 plug

Re: Logger names for nested classes

Dominik, I am so sorry to read that you are struggling with health issue. Thank you so much for taking the time to create the JIRA. We will take it from here and feel free to chime in or contribute at any time :-) I wish you a speedy recovery. Gary On Mon, Aug 14, 2017 at 2:14 AM, Dominik Pse

Re: Logger names for nested classes

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

Re: Logger names for nested classes

Recapping: Using it: 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 > wrote: > > > > Well we can make an exception for trailing $? > > > > Do we want to add an attribute in the Configuration

Re: Logger names for nested classes

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 wrote: > > Well we can make an exception for trailing $? > > Do we want to add an attribute in the Configuration XML element? For > example hierarchySeparators=".

Re: Logger names for nested classes

Sure why not. I just want to nail down the spec before we get caught up in implementation details. Gary On Aug 13, 2017 13:53, "Dominik Psenner" wrote: > What about a LoggerHierarchySeparationStrategy interface along with a > default impl? > > On 13 Aug 2017 9:37 p.m., "Gary Gregory" wrote: >

Re: Logger names for nested classes

What about a LoggerHierarchySeparationStrategy interface along with a default impl? On 13 Aug 2017 9:37 p.m., "Gary Gregory" wrote: > Well we can make an exception for trailing $? > > Do we want to add an attribute in the Configuration XML element? For > example hierarchySeparators=".$/" > > Wha

Re: Logger names for nested classes

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" wrote: > Having the dollar sign interpreted differently also makes a diffe

Re: Logger names for nested classes

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

Re: Logger names for nested classes

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 wrote: > > Yes > >> On 13 Aug 2017 5:13 p.m., "Gary Gregory" wrote: >> >> You are talking about replacing $ with dot in the getLogger

Re: Logger names for nested classes

Yes On 13 Aug 2017 5:13 p.m., "Gary Gregory" wrote: > You are talking about replacing $ with dot in the getLogger(Class) API? > > Gary > > On Aug 13, 2017 01:57, "Dominik Psenner" wrote: > > > Could the $ be replaced by a dot when the logger is instantiated? Log4net > > picks the class name as

Re: Logger names for nested classes

You are talking about replacing $ with dot in the getLogger(Class) API? Gary On Aug 13, 2017 01:57, "Dominik Psenner" 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

Re: Logger names for nested classes

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" wrote: > Rather than implementing this I would rather have the separator chars be > specifiable in the config

Re: Logger names for nested classes

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 wrote: > > Hi All, > > I

Re: Logger names for nested classes

On Sat, Aug 12, 2017 at 1:30 PM, Dominik Psenner wrote: > If it is a private class it might not be sensible to have that class name > in the logfiles. If it is public the class could and should probably be > refactored. ;-) > > I'm only a little afraid of the dollar sign. It is often a bash varia

Re: Logger names for nested classes

If it is a private class it might not be sensible to have that class name in the logfiles. If it is public the class could and should probably be refactored. ;-) I'm only a little afraid of the dollar sign. It is often a bash variable and thus bound to be typo prone when used for greps, configurat

Re: Logger names for nested classes

Hi, Why does that matter? Gary On Aug 12, 2017 12:34, "Dominik Psenner" wrote: > Are the nested classes private or public? > > 2017-08-12 20:29 GMT+02:00 Gary Gregory : > > > Hi All, > > > > I you use nested classes to build loggers, you end up with logger names > > like A$N1, A$N2 and so on.

Re: Logger names for nested classes

Are the nested classes private or public? 2017-08-12 20:29 GMT+02:00 Gary Gregory : > 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 yo

Logger names for nested classes

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