I realized one of my own classes had a builder object/class. The reason I did so was because I had to collect the relevant fields/parameters over time. As the result of progressing through a pattern-recognising state machine. My own target object was immutable, because it represented the result of a tokenizer and should never change; a token / command is a token / command. So it had a number of constructors but in the end the only one that was used was the one with all of the parameters. And it was only used by the Builder ;-).

So now I incorporated it Log4j style and it is better off for it I think (mainClass.newBuilder(), set methods on the builder). The only idiosynchracity that remains is that its builder() function is still called wrapItUp() ;-).

There seem to be three styles you can use to name the methods

- setProperty()
- withProperty()
- property()

I've seen the first two in log4j2.

The with style only makes sense if you complete the build in one go "with .... build". I guess, it really doesn't matter.

As an aside:

*When I started using log4j *I started getting a compiler warning:

[javac] warning: Implicitly compiled files were not subject to annotation pocessing. [javac] Use -proc:none to disable annotation processing or -implicit to specify a policy for implicit compilation.
    [javac] 1 warning

It is probably due to javax.annotation.processing.Processor in log4j-core.jar\META-INF\services ???.

I had to use an ant/javac flag to turn it off:

<javac>
    <compilerarg value="-implicit:class" />
</javac>

By the way, where is the enthusiasm for my pretty colours? Or am I wasting your time? :P. Can be, then I'd better retract myself from this group a bit. Just say the word.... turd ;-).

Regards, and loving you all.

Somewhat.

Bart.




Op 12-8-2015 om 3:32 schreef Ralph Goers:
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


Reply via email to