One of the principals Log4j 2 tries to follow is to create immutable objects as much as possible as it reduces issues with multi- threading. This means not having setter methods. So you are left with builders, or factory methods and/or constructors with a lot of parameters.
Ralph > On Aug 11, 2015, at 2:27 PM, Xen <x...@dds.nl> wrote: > > Op 11-8-2015 om 21:07 schreef Gary Gregory: >> Some appenders use the builder patten, for example >> org.apache.logging.log4j.core.appender.ConsoleAppender.Builder. I'm not sure >> why this appender has both a builder and a create method. Does anyone? Gary > > Builders are nice, I guess. I don't really like that Builder thing from the > Apache Commons but in general it is called a fluid API I believe. Heh, I just > don't like "patterns" when I'm doing the exact same thing except as a > creative endeavour and not something dry as a "pattern". There is a FSM > (state machine) implementation/library that uses the fluid API very well and > very nicely. I try to incorporate it into my own devices as well. > > Because you don't need to end a fluid API with "build" or .build(), the first > method can initialize the construction and any other method just adds to the > complex. Of course any mandatory parameters must be present in the first > method call then and the rest is optional. I think a good constructor > together with appender methods is a better choice: > > conf.addAppender( > new org.apache.logging.log4j.core.appender.ConsoleAppender.Builder(). > setName("ConsoleOwn").setLayout( > org.apache.logging.log4j.core.layout.PatternLayout.createLayout( > myPattern, conf, null, > java.nio.charset.Charset.forName("UTF-8"), > true, false, null, null)).build() > ); > > would become > > conf.addAppender( > new > org.apache.logging.log4j.core.appender.ConsoleAppender("ConsoleOwn").setLayout( > new > org.apache.logging.log4j.core.layout.PatternLayout(conf).setPattern(myPattern). > setCharSet(java.nio.charset.Charset.forName("UTF-8") > ) > ); > > of course it would mean those methods remain available for changing the > object and the cost is that default values are used and subsequently > overwritten. Regardless, the Builder version seems to be nicer than the > createXXXX version. > > But now I realise there is also a PatternLayout.Builder :D. I was even > beginning to assume that I could offer to write one :P. > > Here it goes. > > conf.addAppender( > org.apache.logging.log4j.core.appender.ConsoleAppender.newBuilder(). > setName("ConsoleOwn"). > setLayout( > org.apache.logging.log4j.core.layout.PatternLayout.newBuilder(). > withPattern(myPattern). > withCharset(java.nio.charset.Charset.forName("UTF-8")). > withConfiguration(conf). > build()). > build() > ); > > So thank you for the suggestion Gary. If you guys want any Builder written > for any class in return, let me know. I'd be happy to contribute a class. In > return, I guess. > > Just let me know which class would need a builder, and what the style of the > methods should be (set or with). > > Regards, kudos. > > Bart. > > >>> - appenders need to be added twice >>> - if you create an appender with the same name it will not add it but give >>> no error >>> - various static methods from different classes do important things, but >>> it is not centralized. >>> - maybe there is too much static in any case, but yeah. >>> >>> JAnsi works. I'm doing stuff JAnsi does, and there is already an entire >>> package that does everything I would want or need to do :P. Go figure. Now >>> it is even included with my application just to make it work on Windows, >>> and I don't really want to use it with my default application ;-). (Maybe >>> I'll have to, given that). Ooh but it doesn't do input >>> processing/filtering, I might even use it. (My library parses ANSI tokens). >>> >>> Anyway to cut it short now, here is a screenshot of what I've been doing: >>> >>> http://www.xen.dds.nl/f/i/screenshots/thunderbolt-log4j-reward.png >>> >>> The first field is the thread in blue, there are three threads (thread >>> types): main, server and client. Every client thread gets numbered from a >>> pool that gets refilled when a thread exits (just a Set I take numbers out >>> of and I always take the first one (SortedSet/TreeSet)). After that is the >>> logger name. I don't name my loggers anymore by class but by subsystem. >>> Essentially, by package, I guess. There are only two packages / subsystems >>> at the moment that are being shown a third is called "telnet.file" and I >>> haven't tested it yet. >>> >>> It's just that my FileAppender doesn't yet work. However since it >>> "additives" from "telnet" it also outputs to the console: >>> >>> http://www.xen.dds.nl/f/i/screenshots/thunderbolt-log4j-reward2.smaller.png >>> >>> Fixed. >>> >>> So I have 3 loggerconfigs now: >>> - "server" --> outputs to root logger >>> - "telnet" --> outputs to root logger >>> - "telnet.file" --> additionally outputs to a log file. >>> >>> Regards, and enjoy :p. >>> >>> Bart. >>> >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org >>> For additional commands, e-mail: log4j-user-h...@logging.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org > For additional commands, e-mail: log4j-user-h...@logging.apache.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-user-h...@logging.apache.org