Re: Logger names for nested classes

[Gary Gregory]

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)
>
> 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  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 
> > 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 
> > 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 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  > >>> 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 
> 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:
> > >
> > >> 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 :
> > >>
> > >>> 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 <
> > >>> 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  >
> > >> 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 

Re: Logger names for nested classes

[Matt Sicker]

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  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 
> 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 
> 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 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  >>> 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  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:
> >
> >> 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 :
> >>
> >>> 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 <
> >>> 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 
> >> 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 

Re: Logger names for nested classes

[Remko Popma]

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  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  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 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 >> hierarchySeparators="./$" ... Is my understanding correct?
>>> 
>>> 
>>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers 
>>> wrote:
>>> 
 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:
> 
>> 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 :
>> 
>>> 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 <
>>> 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 
>> 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
>>> >
 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:
>> 
>> 

Re: Logger names for nested classes

[Ralph Goers]

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 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 > hierarchySeparators="./$" ... Is my understanding correct?
>> 
>> 
>> On Sun, Aug 20, 2017 at 3:47 AM, Ralph Goers 
>> wrote:
>> 
>>> 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:
 
> 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 :
> 
>> 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 <
>> 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 
> 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
>> >
>>> 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 

Re: Logger names for nested classes

[Remko Popma]

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 
wrote:

> 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:
> >
> >> 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 :
> >>
> >>> 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 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 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  >
> >> 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
> >>> >
>  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 
> >>
> >
> >
> 
> >>>
> >>
> >>
> >>
> >> --
> >> Dominik Psenner
> >>
> >
> >
> >
> > --
> > Matt Sicker 
>
>
>

Re: Logger names for nested classes

[Ralph Goers]

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:
> 
>> 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 :
>> 
>>> 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 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 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 
>> 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
>>> >
 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 
>> 
> 
> 
 
>>> 
>> 
>> 
>> 
>> --
>> Dominik Psenner
>> 
> 
> 
> 
> -- 
> Matt Sicker 

Re: Logger names for nested classes

[Matt Sicker]

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
> 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 :
>
> > 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 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 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 
> > >>> 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
> > >>> > >
> > >>> > > 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 
> > >>>
> > >>
> > >>
> > >
> >
>
>
>
> --
> Dominik Psenner
>



-- 
Matt Sicker 

Re: Logger names for nested classes

[Dominik Psenner]

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 :

> 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 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 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 
> >>> wrote:
> >>>
> >>> >
> >>> > > On Aug 14, 2017, at 1:38 PM, Gary Gregory 
> >>> > wrote:
> >>> > >
> >>> > > On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
> >>> 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 
> >>>
> >>
> >>
> >
>



-- 
Dominik Psenner

Re: Logger names for nested classes

[Gary Gregory]

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 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 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 
>>> wrote:
>>>
>>> >
>>> > > On Aug 14, 2017, at 1:38 PM, Gary Gregory 
>>> > wrote:
>>> > >
>>> > > On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com
>>> > >
>>> > > wrote:
>>> > >
>>> > >>
>>> > >>> On Aug 14, 2017, at 11:49 AM, Gary Gregory >> >
>>> > >> 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 
>>>
>>
>>
>

Re: Logger names for nested classes

[Gary Gregory]

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 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 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 
>> wrote:
>>
>> >
>> > > On Aug 14, 2017, at 1:38 PM, Gary Gregory 
>> > wrote:
>> > >
>> > > On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
>> ralph.go...@dslextreme.com
>> > >
>> > > wrote:
>> > >
>> > >>
>> > >>> On Aug 14, 2017, at 11:49 AM, Gary Gregory 
>> > >> 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 
>>
>
>

Re: Logger names for nested classes

[Gary Gregory]

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 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 
> wrote:
>
> >
> > > On Aug 14, 2017, at 1:38 PM, Gary Gregory 
> > wrote:
> > >
> > > On Mon, Aug 14, 2017 at 2:08 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> > >
> > > wrote:
> > >
> > >>
> > >>> On Aug 14, 2017, at 11:49 AM, Gary Gregory 
> > >> 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 
>

Re: Logger names for nested classes

[Ralph Goers]

> 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:
>>> 
 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

Re: Logger names for nested classes

[Gary Gregory]

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
> >> 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.

Gary


> Ralph
>
>
>

Re: Logger names for nested classes

[Ralph Goers]

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

Ralph

Re: Logger names for nested classes

[Dominik Psenner]

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 games with the
kids for an hour with the pain coming back only very slowly. Rest assured
that I'm going to stick around, even though other things are more important
right now.

Cheers and hoping to read you soon!

2017-08-14 20:05 GMT+02:00 Gary Gregory :

> 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 Psenner 
> 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 :
> >
> > > Recapping:
> > >
> > > Using it:
> > >
> > >  > >
> > > Default:
> > >
> > >  > >
> > > Dominik: Do you want to take a shot at it?
> > >
> > > Gary
> > >
> > >
> > >
> > > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
> ralph.go...@dslextreme.com
> > >
> > > 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 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
> > 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 
> > > 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 <
> dpsen...@gmail.com>
> > > > >> wrote:
> > > > 
> > > >  Yes
> > > > 
> > > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
> garydgreg...@gmail.com
> > >
> > > > >>> 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 logger name but also allows custom
> > logger
> > > > >>> names.
> > > > >>
> > > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > > ralph.go...@dslextreme.com
> > > > >
> > > > >> 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 <
> > > > garydgreg...@gmail.com
> > > > >>>
> > > > >>> 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 "$" 

Re: Logger names for nested classes

[Gary Gregory]

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 
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 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 
>> 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 :
>>>
>>> > Recapping:
>>> >
>>> > Using it:
>>> >
>>> > >> >
>>> > Default:
>>> >
>>> > >> >
>>> > Dominik: Do you want to take a shot at it?
>>> >
>>> > Gary
>>> >
>>> >
>>> >
>>> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
>>> ralph.go...@dslextreme.com>
>>> > 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 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
>>> 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 
>>> > 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 <
>>> dpsen...@gmail.com>
>>> > > >> wrote:
>>> > > 
>>> > >  Yes
>>> > > 
>>> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
>>> garydgreg...@gmail.com>
>>> > > >>> 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 logger name but also allows custom
>>> logger
>>> > > >>> names.
>>> > > >>
>>> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
>>> > ralph.go...@dslextreme.com
>>> > > >
>>> > > >> 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 <
>>> > > garydgreg...@gmail.com
>>> > > >>>
>>> > > >>> wrote:
>>> > > 
>>> > >  Hi All,
>>> > > 
>>> > >  I you use nested classes to build 

Re: Logger names for nested classes

[Gary Gregory]

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 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 
> 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 :
>>
>> > Recapping:
>> >
>> > Using it:
>> >
>> > > >
>> > Default:
>> >
>> > > >
>> > Dominik: Do you want to take a shot at it?
>> >
>> > Gary
>> >
>> >
>> >
>> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers <
>> ralph.go...@dslextreme.com>
>> > 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 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
>> 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 
>> > 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 > >
>> > > >> wrote:
>> > > 
>> > >  Yes
>> > > 
>> > > > On 13 Aug 2017 5:13 p.m., "Gary Gregory" <
>> garydgreg...@gmail.com>
>> > > >>> 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 logger name but also allows custom
>> logger
>> > > >>> names.
>> > > >>
>> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
>> > ralph.go...@dslextreme.com
>> > > >
>> > > >> 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 <
>> > > garydgreg...@gmail.com
>> > > >>>
>> > > >>> 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 

Re: Logger names for nested classes

[Gary Gregory]

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.

Gary


On Mon, Aug 14, 2017 at 2:14 AM, Dominik Psenner  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 :
>
> > Recapping:
> >
> > Using it:
> >
> >  >
> > Default:
> >
> >  >
> > Dominik: Do you want to take a shot at it?
> >
> > Gary
> >
> >
> >
> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers  >
> > 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 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
> 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 
> > 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 
> > > >> wrote:
> > > 
> > >  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 logger name but also allows custom
> logger
> > > >>> names.
> > > >>
> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > ralph.go...@dslextreme.com
> > > >
> > > >> 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 <
> > > garydgreg...@gmail.com
> > > >>>
> > > >>> 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 
> > > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Logger names for nested classes

[Gary Gregory]

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 Psenner  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 :
>
> > Recapping:
> >
> > Using it:
> >
> >  >
> > Default:
> >
> >  >
> > Dominik: Do you want to take a shot at it?
> >
> > Gary
> >
> >
> >
> > On Sun, Aug 13, 2017 at 2:58 PM, Ralph Goers  >
> > 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 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
> 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 
> > 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 
> > > >> wrote:
> > > 
> > >  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 logger name but also allows custom
> logger
> > > >>> names.
> > > >>
> > > >> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > ralph.go...@dslextreme.com
> > > >
> > > >> 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 <
> > > garydgreg...@gmail.com
> > > >>>
> > > >>> 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 
> > > >>
> > >
> > >
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Logger names for nested classes

[Gary Gregory]

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 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 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  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 
> >> wrote:
> 
>  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 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 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 <
> garydgreg...@gmail.com
> >>>
> >>> 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 
> >>
>
>
>

Re: Logger names for nested classes

[Gary Gregory]

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:
>
> > 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 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  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 
> > > wrote:
> > > > >
> > > > > 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 logger name but also allows custom logger
> > > > names.
> > > > >>>
> > > > >>> On 13 Aug 2017 8:30 a.m., "Ralph Goers" <
> > ralph.go...@dslextreme.com>
> > > > >>> 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 <
> > garydgreg...@gmail.com
> > > >
> > > >  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 
> > >
> >
>

Re: Logger names for nested classes

[Gary Gregory]

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 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  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 
> wrote:
> > >
> > > 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 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 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 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 
>

Re: Logger names for nested classes

[Matt Sicker]

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  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  wrote:
> >
> > 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 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 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 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 

Re: Logger names for nested classes

[Apache]

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(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 8:30 a.m., "Ralph Goers" 
>>> 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 
 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
 
 
 
>>> 
>> 

Re: Logger names for nested classes

[Gary Gregory]

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 8:30 a.m., "Ralph Goers" 
> 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 
> > 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
> >
> >
> >
>

Re: Logger names for nested classes

[Ralph Goers]

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 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

Re: Logger names for nested classes

[Gary Gregory]

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 variable
> and thus bound to be typo prone when used for greps, configurations, ..
>
> Could a logger name attribute be an option?
>

What do you mean?

Gary

>
> 2017-08-12 20:44 GMT+02:00 Gary Gregory :
>
> > 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.
> > > >
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Dominik Psenner
> > >
> >
>
>
>
> --
> Dominik Psenner
>

Re: Logger names for nested classes

[Dominik Psenner]

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, configurations, ..

Could a logger name attribute be an option?

2017-08-12 20:44 GMT+02:00 Gary Gregory :

> 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.
> > >
> > > 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
> > >
> >
> >
> >
> > --
> > Dominik Psenner
> >
>



-- 
Dominik Psenner

Re: Logger names for nested classes

[Gary Gregory]

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.
> >
> > 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
> >
>
>
>
> --
> Dominik Psenner
>

Re: Logger names for nested classes

[Dominik Psenner]

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 you might expect, since "$" is not a ".".
>
> What about treating "$" like a "."?
>
> Thoughts?
>
> Gary
>



-- 
Dominik Psenner