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