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
