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 <[email protected]> wrote:
> On Tue, Mar 10, 2020 at 12:06 PM Ralph Goers <[email protected]>
> wrote:
>
>>
>>
>> > On Mar 10, 2020, at 8:40 AM, Gary Gregory <[email protected]>
>> 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
>>
>>
>>
>>
>>
