Re: my results thus far

[Xen]

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:





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

Re: my results thus far

[Mikael Ståldal]

Too bad that Java lacks named parameters to methods and constructors (as
languages like Python and Scala have).

On Wed, Aug 12, 2015 at 3:32 AM, Ralph Goers 
wrote:

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

Re: my results thus far

[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  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 
> create 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
>>> 
>>> Fixe

Re: my results thus far

[Xen]

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

Re: my results thus far

[Gary Gregory]

On Tue, Aug 11, 2015 at 11:11 AM, Xen  wrote:

> Hi, I just wanted to give a little back of what I've been doing.
>
> I can say programmatic configuration the way it is is *really* hard.
>
> Mostly it is hard because of
>
> - having to import a million different things from different packages, and
> you can never guess or remember which package it is going to be
> - the creator methods take a million parameters
>

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


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
Java Persistence with Hibernate, Second Edition

JUnit in Action, Second Edition 
Spring Batch in Action 
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory