Thanks for your response Jacob.
I've been looking at the additive feature, but I'm not sure it solves my
requirement.
Given this configuration, I would like to debug class X on appender A, but
still keep the info level messages from class X on appender B.
I was hoping that this line would make t
I create a JIRA to track possible solutions:
https://issues.apache.org/jira/browse/LOG4J2-415
I have attached two different solutions in a patch file.
Gary
On Mon, Sep 30, 2013 at 11:33 PM, Gary Gregory wrote:
> Hello Ed,
>
> This is what Log4j 2 can do now WRT to time stamp formatting:
> http
On Tue, 1 Oct 2013 18:17:41 +0200
fedinho wrote:
Hi.
A simple question I hope someone can help me with. This is using log4j 1.2.x
I would like to log info level to one appender A and warn level to another
appenderB.
However, I would like to log debug messages from class X to appender A, and
Hi.
A simple question I hope someone can help me with. This is using log4j 1.2.x
I would like to log info level to one appender A and warn level to another
appenderB.
However, I would like to log debug messages from class X to appender A, and
debug messages from class Y to appender B.
Thanks fo
I have created a JIRA ticket for this issue.
Please let me know if you need more detail. I can also do more test as you
instruct.
thanks a lot
Yiru
On Mon, Sep 30, 2013 at 10:52 PM, Remko Popma wrote:
> Thank you for reporting this.
> Can I ask you to create a JIRA ticket for this issue? Can y
Thanks Remko for the valuable insight on queue size and ring buffer size in
log4j and logback. I will make adjustments to the settings and run the
test again.
On Tue, Oct 1, 2013 at 10:02 AM, Remko Popma wrote:
> Michael,
>
> I finally got around to looking at the test results you posted on Gi
Michael,
I finally got around to looking at the test results you posted on Github (
https://github.com/michaelzhou999/logging-profiling).
Very extensive testing, I can tell you put a lot of work into it!
I was initially a bit surprised by your Log4J2 finding that at ten threads
or more, synchron
Patches are always welcome!
Ralph
On Oct 1, 2013, at 1:13 AM, Oliver Flege wrote:
>> $${mdc:request_id} in a pattern should cause the request_id to be evaluated
>> on every event.
>
> thanks a lot, $${ctx:request_id} seems to do the trick
>
> however, the computation of the default value is
How common is a single core any more? I suppose it might be common I embedded
systems.
Ralph
> On Sep 30, 2013, at 11:55 PM, Roland wrote:
>
> Very interesting...
> All tests were performed with a dual core. But what results can we expect if
> single core is used?
>
> Thanks!
>
>
>
> --
>
> $${mdc:request_id} in a pattern should cause the request_id to be evaluated
> on every event.
>
thanks a lot, $${ctx:request_id} seems to do the trick
however, the computation of the default value is quite complex as it always
involves
a variable substitution, and I cannot use conversion spe
10 matches
Mail list logo