You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-user@logging.apache.org by Xen <xe...@dds.nl> on 2015/08/11 20:11:13 UTC
my results thus far
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
- 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-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: my results thus far
Posted by Mikael Ståldal <mi...@magine.com>.
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 <ra...@dslextreme.com>
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 <xe...@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-unsubscribe@logging.apache.org
> >>> For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> > For additional commands, e-mail: log4j-user-help@logging.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
[image: MagineTV]
*Mikael Ståldal*
Senior backend developer
*Magine TV*
mikael.staldal@magine.com
Regeringsgatan 25 | 111 53 Stockholm, Sweden | www.magine.com
Privileged and/or Confidential Information may be contained in this
message. If you are not the addressee indicated in this message
(or responsible for delivery of the message to such a person), you may not
copy or deliver this message to anyone. In such case,
you should destroy this message and kindly notify the sender by reply
email.
Re: my results thus far
Posted by Xen <xe...@dds.nl>.
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 <xe...@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-unsubscribe@logging.apache.org
>>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
Re: my results thus far
Posted by Ralph Goers <ra...@dslextreme.com>.
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 <xe...@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-unsubscribe@logging.apache.org
>>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: my results thus far
Posted by Xen <xe...@dds.nl>.
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-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-user-help@logging.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-user-help@logging.apache.org
Re: my results thus far
Posted by Gary Gregory <ga...@gmail.com>.
On Tue, Aug 11, 2015 at 11:11 AM, Xen <xe...@dds.nl> 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-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-user-help@logging.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory