You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@logging.apache.org by Gary Gregory <ga...@gmail.com> on 2020/03/09 14:51:14 UTC
[log4j] getLogger(String... name)?
Hi All:
Any thought for or against adding the API 'getLogger(String... name)' which
would build a hierarchical logger name. These would be equivalent:
- getLogger("com.a.b.c")
- getLogger("com", "a", "b", "c")
Gary
Re: [log4j] getLogger(String... name)?
Posted by Carter Kozak <ck...@ckozak.net>.
Yes, I was agreeing with you, Ralph. My (poorly articulated) point was that concatenation can be optimized by the compiler as you mentioned, in addition to cases where not all of the values are known at compile time. Sorry for the confusion!
-ck
On Tue, Mar 10, 2020, at 11:13, Ralph Goers wrote:
> Even with that, it is still no match for string concatenation performed by the compiler. Notice that Gary’s example is concatenating two constants. The compiler can detect that and concatenate them into a single string during compilation.
>
> In any case, using the comma operator means we would have to perform the concatenation instead of letting the compiler do it. This might make sense if there was some use case where the concatenation was going to be avoided like we have in logging calls, but the isn’t the case.
>
> I just can’t think of a reason why this would be “better”.
>
> Ralph
>
> > On Mar 10, 2020, at 7:34 AM, Carter Kozak <ck...@ckozak.net> wrote:
> >
> > Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string concatenation with dynamic values more performant than string builders. That said, requesting loggers from the context is already relatively expensive and isn't expected to be on hot paths.
> >
> > -ck
> >
> > On Tue, Mar 10, 2020, at 10:32, Ralph Goers wrote:
> >> Cleaner? You changed a plus sign to a comma and turned the concatenation from happening at compile time to runtime. Even if you could I would argue you shouldn’t.
> >>
> >> Ralph
> >>
> >>> On Mar 10, 2020, at 7:10 AM, Gary Gregory <ga...@gmail.com> wrote:
> >>>
> >>> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <ra...@dslextreme.com>
> >>> wrote:
> >>>
> >>>> Why would you want to do that? Most people seem to prefer getLogger()
> >>>> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
> >>>> want to dynamically construct a name like that and if they did, why
> >>>> wouldn’t they just using StringBuilder?
> >>>>
> >>>
> >>> I have a logger name root name in a constant like ROOT_LOGGER_NAME and
> >>> right now I create a hierarchy like akin to this:
> >>>
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
> >>>
> >>> This could all be clearer if the API was a String... instead of a String.
> >>>
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
> >>>
> >>> Gary
> >>>
> >>>
> >>>> Ralph
> >>>>
> >>>>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
> >>>>>
> >>>>> Hi All:
> >>>>>
> >>>>> Any thought for or against adding the API 'getLogger(String... name)'
> >>>> which
> >>>>> would build a hierarchical logger name. These would be equivalent:
> >>>>>
> >>>>> - getLogger("com.a.b.c")
> >>>>> - getLogger("com", "a", "b", "c")
> >>>>>
> >>>>> Gary
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >
>
>
>
Re: [log4j] getLogger(String... name)?
Posted by Ralph Goers <ra...@dslextreme.com>.
It would be fun to do a JMH benchmark on String concatenation vs String.join. But yes, that is exactly what I was suggesting.
Ralph
> On Mar 11, 2020, at 8:09 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Java 8 to the rescue somewhat:
>
> loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "foo", "bar"));
> loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "boo", "baz"));
>
> Gary
>
> On Tue, Mar 10, 2020 at 4:33 PM Gary Gregory <ga...@gmail.com> wrote:
>
>> On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers <ra...@dslextreme.com>
>> wrote:
>>
>>>
>>>
>>>> On Mar 10, 2020, at 8:40 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>>>
>>>> My POV has nothing to do with performance, more about code clarity.
>>>> Building strings 'manually' can be error/typo prone, you can type a ','
>>>> instead of a '.' for example. The idea being using String... was to
>>>> formalize the split of hierarchical elements just like you see in APIs
>>>> like java.nio.file.Paths.get(String, String…)
>>>
>>> This would make sense if you were constructing Loggers from their
>>> parents, but even that doesn’t make sense since Loggers declared in classes
>>> are generally terminal (i.e. - no children).
>>>
>>
>> These are not the usual one-logger-per-Java-class Loggers, these are for
>> higher-level abstractions in this app (details are not important but
>> involve MapMessage that end up in JDBC and JMS appenders.)
>>
>>
>>> I would argue that if you really want to do this create a utility method
>>> that constructs the string and pass that to getLogger() - such as
>>> getLogger(nameBuilder(ROOT).append(NEXT).append(FINAL).build()); or
>>> something similar. But I would think a name builder like this would have
>>> more of a place in Commons Text than here.
>>>
>>
>> I see what you are saying but I am not sure I want to go that route.
>>
>> I might have to leave it as is since this proposal is presents more
>> friction than I thought.
>>
>> Thank you all for sounding this out.
>>
>> Gary
>>
>>
>>> Ralph
>>>
>>>
>>>
>>>
>>>
Re: [log4j] getLogger(String... name)?
Posted by Gary Gregory <ga...@gmail.com>.
Java 8 to the rescue somewhat:
loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "foo", "bar"));
loggerContext.getLogger(String.join(".", MY_ROOT_NAME, "boo", "baz"));
Gary
On Tue, Mar 10, 2020 at 4:33 PM Gary Gregory <ga...@gmail.com> wrote:
> On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>>
>>
>> > On Mar 10, 2020, at 8:40 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> >
>> > My POV has nothing to do with performance, more about code clarity.
>> > Building strings 'manually' can be error/typo prone, you can type a ','
>> > instead of a '.' for example. The idea being using String... was to
>> > formalize the split of hierarchical elements just like you see in APIs
>> > like java.nio.file.Paths.get(String, String…)
>>
>> This would make sense if you were constructing Loggers from their
>> parents, but even that doesn’t make sense since Loggers declared in classes
>> are generally terminal (i.e. - no children).
>>
>
> These are not the usual one-logger-per-Java-class Loggers, these are for
> higher-level abstractions in this app (details are not important but
> involve MapMessage that end up in JDBC and JMS appenders.)
>
>
>> I would argue that if you really want to do this create a utility method
>> that constructs the string and pass that to getLogger() - such as
>> getLogger(nameBuilder(ROOT).append(NEXT).append(FINAL).build()); or
>> something similar. But I would think a name builder like this would have
>> more of a place in Commons Text than here.
>>
>
> I see what you are saying but I am not sure I want to go that route.
>
> I might have to leave it as is since this proposal is presents more
> friction than I thought.
>
> Thank you all for sounding this out.
>
> Gary
>
>
>> Ralph
>>
>>
>>
>>
>>
Re: [log4j] getLogger(String... name)?
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers <ra...@dslextreme.com>
wrote:
>
>
> > On Mar 10, 2020, at 8:40 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >
> > My POV has nothing to do with performance, more about code clarity.
> > Building strings 'manually' can be error/typo prone, you can type a ','
> > instead of a '.' for example. The idea being using String... was to
> > formalize the split of hierarchical elements just like you see in APIs
> > like java.nio.file.Paths.get(String, String…)
>
> This would make sense if you were constructing Loggers from their parents,
> but even that doesn’t make sense since Loggers declared in classes are
> generally terminal (i.e. - no children).
>
These are not the usual one-logger-per-Java-class Loggers, these are for
higher-level abstractions in this app (details are not important but
involve MapMessage that end up in JDBC and JMS appenders.)
> I would argue that if you really want to do this create a utility method
> that constructs the string and pass that to getLogger() - such as
> getLogger(nameBuilder(ROOT).append(NEXT).append(FINAL).build()); or
> something similar. But I would think a name builder like this would have
> more of a place in Commons Text than here.
>
I see what you are saying but I am not sure I want to go that route.
I might have to leave it as is since this proposal is presents more
friction than I thought.
Thank you all for sounding this out.
Gary
> Ralph
>
>
>
>
>
Re: [log4j] getLogger(String... name)?
Posted by Ralph Goers <ra...@dslextreme.com>.
> On Mar 10, 2020, at 8:40 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> My POV has nothing to do with performance, more about code clarity.
> Building strings 'manually' can be error/typo prone, you can type a ','
> instead of a '.' for example. The idea being using String... was to
> formalize the split of hierarchical elements just like you see in APIs
> like java.nio.file.Paths.get(String, String…)
This would make sense if you were constructing Loggers from their parents, but even that doesn’t make sense since Loggers declared in classes are generally terminal (i.e. - no children).
I would argue that if you really want to do this create a utility method that constructs the string and pass that to getLogger() - such as getLogger(nameBuilder(ROOT).append(NEXT).append(FINAL).build()); or something similar. But I would think a name builder like this would have more of a place in Commons Text than here.
Ralph
Re: [log4j] getLogger(String... name)?
Posted by Gary Gregory <ga...@gmail.com>.
My POV has nothing to do with performance, more about code clarity.
Building strings 'manually' can be error/typo prone, you can type a ','
instead of a '.' for example. The idea being using String... was to
formalize the split of hierarchical elements just like you see in APIs
like java.nio.file.Paths.get(String, String...)
Gary
On Tue, Mar 10, 2020 at 11:14 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> Even with that, it is still no match for string concatenation performed by
> the compiler. Notice that Gary’s example is concatenating two constants.
> The compiler can detect that and concatenate them into a single string
> during compilation.
>
> In any case, using the comma operator means we would have to perform the
> concatenation instead of letting the compiler do it. This might make sense
> if there was some use case where the concatenation was going to be avoided
> like we have in logging calls, but the isn’t the case.
>
> I just can’t think of a reason why this would be “better”.
>
> Ralph
>
> > On Mar 10, 2020, at 7:34 AM, Carter Kozak <ck...@ckozak.net> wrote:
> >
> > Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string
> concatenation with dynamic values more performant than string builders.
> That said, requesting loggers from the context is already relatively
> expensive and isn't expected to be on hot paths.
> >
> > -ck
> >
> > On Tue, Mar 10, 2020, at 10:32, Ralph Goers wrote:
> >> Cleaner? You changed a plus sign to a comma and turned the
> concatenation from happening at compile time to runtime. Even if you could
> I would argue you shouldn’t.
> >>
> >> Ralph
> >>
> >>> On Mar 10, 2020, at 7:10 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>>
> >>> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <
> ralph.goers@dslextreme.com>
> >>> wrote:
> >>>
> >>>> Why would you want to do that? Most people seem to prefer getLogger()
> >>>> while I prefer getLogger(MyClass.class). I can’t imagine why anyone
> would
> >>>> want to dynamically construct a name like that and if they did, why
> >>>> wouldn’t they just using StringBuilder?
> >>>>
> >>>
> >>> I have a logger name root name in a constant like ROOT_LOGGER_NAME and
> >>> right now I create a hierarchy like akin to this:
> >>>
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
> >>>
> >>> This could all be clearer if the API was a String... instead of a
> String.
> >>>
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
> >>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
> >>>
> >>> Gary
> >>>
> >>>
> >>>> Ralph
> >>>>
> >>>>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> >>>>>
> >>>>> Hi All:
> >>>>>
> >>>>> Any thought for or against adding the API 'getLogger(String... name)'
> >>>> which
> >>>>> would build a hierarchical logger name. These would be equivalent:
> >>>>>
> >>>>> - getLogger("com.a.b.c")
> >>>>> - getLogger("com", "a", "b", "c")
> >>>>>
> >>>>> Gary
> >>>>
> >>>>
> >>>>
> >>
> >>
> >>
> >
>
>
>
Re: [log4j] getLogger(String... name)?
Posted by Ralph Goers <ra...@dslextreme.com>.
Even with that, it is still no match for string concatenation performed by the compiler. Notice that Gary’s example is concatenating two constants. The compiler can detect that and concatenate them into a single string during compilation.
In any case, using the comma operator means we would have to perform the concatenation instead of letting the compiler do it. This might make sense if there was some use case where the concatenation was going to be avoided like we have in logging calls, but the isn’t the case.
I just can’t think of a reason why this would be “better”.
Ralph
> On Mar 10, 2020, at 7:34 AM, Carter Kozak <ck...@ckozak.net> wrote:
>
> Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string concatenation with dynamic values more performant than string builders. That said, requesting loggers from the context is already relatively expensive and isn't expected to be on hot paths.
>
> -ck
>
> On Tue, Mar 10, 2020, at 10:32, Ralph Goers wrote:
>> Cleaner? You changed a plus sign to a comma and turned the concatenation from happening at compile time to runtime. Even if you could I would argue you shouldn’t.
>>
>> Ralph
>>
>>> On Mar 10, 2020, at 7:10 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <ra...@dslextreme.com>
>>> wrote:
>>>
>>>> Why would you want to do that? Most people seem to prefer getLogger()
>>>> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
>>>> want to dynamically construct a name like that and if they did, why
>>>> wouldn’t they just using StringBuilder?
>>>>
>>>
>>> I have a logger name root name in a constant like ROOT_LOGGER_NAME and
>>> right now I create a hierarchy like akin to this:
>>>
>>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
>>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
>>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
>>> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
>>>
>>> This could all be clearer if the API was a String... instead of a String.
>>>
>>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
>>> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
>>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
>>> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
>>>
>>> Gary
>>>
>>>
>>>> Ralph
>>>>
>>>>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>>>
>>>>> Hi All:
>>>>>
>>>>> Any thought for or against adding the API 'getLogger(String... name)'
>>>> which
>>>>> would build a hierarchical logger name. These would be equivalent:
>>>>>
>>>>> - getLogger("com.a.b.c")
>>>>> - getLogger("com", "a", "b", "c")
>>>>>
>>>>> Gary
>>>>
>>>>
>>>>
>>
>>
>>
>
Re: [log4j] getLogger(String... name)?
Posted by Carter Kozak <ck...@ckozak.net>.
Jdk9+ provides https://openjdk.java.net/jeps/280 which makes string concatenation with dynamic values more performant than string builders. That said, requesting loggers from the context is already relatively expensive and isn't expected to be on hot paths.
-ck
On Tue, Mar 10, 2020, at 10:32, Ralph Goers wrote:
> Cleaner? You changed a plus sign to a comma and turned the concatenation from happening at compile time to runtime. Even if you could I would argue you shouldn’t.
>
> Ralph
>
> > On Mar 10, 2020, at 7:10 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <ra...@dslextreme.com>
> > wrote:
> >
> >> Why would you want to do that? Most people seem to prefer getLogger()
> >> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
> >> want to dynamically construct a name like that and if they did, why
> >> wouldn’t they just using StringBuilder?
> >>
> >
> > I have a logger name root name in a constant like ROOT_LOGGER_NAME and
> > right now I create a hierarchy like akin to this:
> >
> > loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
> > loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
> > loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
> > loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
> >
> > This could all be clearer if the API was a String... instead of a String.
> >
> > loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
> > loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
> > loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
> > loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
> >
> > Gary
> >
> >
> >> Ralph
> >>
> >>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
> >>>
> >>> Hi All:
> >>>
> >>> Any thought for or against adding the API 'getLogger(String... name)'
> >> which
> >>> would build a hierarchical logger name. These would be equivalent:
> >>>
> >>> - getLogger("com.a.b.c")
> >>> - getLogger("com", "a", "b", "c")
> >>>
> >>> Gary
> >>
> >>
> >>
>
>
>
Re: [log4j] getLogger(String... name)?
Posted by Ralph Goers <ra...@dslextreme.com>.
Cleaner? You changed a plus sign to a comma and turned the concatenation from happening at compile time to runtime. Even if you could I would argue you shouldn’t.
Ralph
> On Mar 10, 2020, at 7:10 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <ra...@dslextreme.com>
> wrote:
>
>> Why would you want to do that? Most people seem to prefer getLogger()
>> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
>> want to dynamically construct a name like that and if they did, why
>> wouldn’t they just using StringBuilder?
>>
>
> I have a logger name root name in a constant like ROOT_LOGGER_NAME and
> right now I create a hierarchy like akin to this:
>
> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
> loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
> loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
>
> This could all be clearer if the API was a String... instead of a String.
>
> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
> loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
> loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
>
> Gary
>
>
>> Ralph
>>
>>> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>>>
>>> Hi All:
>>>
>>> Any thought for or against adding the API 'getLogger(String... name)'
>> which
>>> would build a hierarchical logger name. These would be equivalent:
>>>
>>> - getLogger("com.a.b.c")
>>> - getLogger("com", "a", "b", "c")
>>>
>>> Gary
>>
>>
>>
Re: [log4j] getLogger(String... name)?
Posted by Gary Gregory <ga...@gmail.com>.
On Mon, Mar 9, 2020 at 11:10 AM Ralph Goers <ra...@dslextreme.com>
wrote:
> Why would you want to do that? Most people seem to prefer getLogger()
> while I prefer getLogger(MyClass.class). I can’t imagine why anyone would
> want to dynamically construct a name like that and if they did, why
> wouldn’t they just using StringBuilder?
>
I have a logger name root name in a constant like ROOT_LOGGER_NAME and
right now I create a hierarchy like akin to this:
loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.request");
loggerContext.getLogger(ROOT_LOGGER_NAME + ".client.response");
loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.request");
loggerContext.getLogger(ROOT_LOGGER_NAME + ".server.response");
This could all be clearer if the API was a String... instead of a String.
loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, REQUEST);
loggerContext.getLogger(ROOT_LOGGER_NAME, CLIENT, RESPONSE);
loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, REQUEST);
loggerContext.getLogger(ROOT_LOGGER_NAME, SERVER, RESPONSE );
Gary
> Ralph
>
> > On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
> >
> > Hi All:
> >
> > Any thought for or against adding the API 'getLogger(String... name)'
> which
> > would build a hierarchical logger name. These would be equivalent:
> >
> > - getLogger("com.a.b.c")
> > - getLogger("com", "a", "b", "c")
> >
> > Gary
>
>
>
Re: [log4j] getLogger(String... name)?
Posted by Ralph Goers <ra...@dslextreme.com>.
Why would you want to do that? Most people seem to prefer getLogger() while I prefer getLogger(MyClass.class). I can’t imagine why anyone would want to dynamically construct a name like that and if they did, why wouldn’t they just using StringBuilder?
Ralph
> On Mar 9, 2020, at 7:51 AM, Gary Gregory <ga...@gmail.com> wrote:
>
> Hi All:
>
> Any thought for or against adding the API 'getLogger(String... name)' which
> would build a hierarchical logger name. These would be equivalent:
>
> - getLogger("com.a.b.c")
> - getLogger("com", "a", "b", "c")
>
> Gary