Oh man I read that so wrong I looked like a bot responding to questions!
On 15 March 2016 at 17:47, Ralph Goers wrote:
> I think he means that isEnabled would check the all filters. This would
> have a major negative impact on performance so fo that reason I would be
> against such a change.
>
I think he means that isEnabled would check the all filters. This would have a
major negative impact on performance so fo that reason I would be against such
a change.
Ralph
> On Mar 15, 2016, at 1:13 PM, Matt Sicker wrote:
>
> You can apply filters to appenders and loggers. There are actual
[
https://issues.apache.org/jira/browse/LOG4J2-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194801#comment-15194801
]
Remko Popma edited comment on LOG4J2-1295 at 3/15/16 8:52 PM:
-
You can apply filters to appenders and loggers. There are actually four
different places you can apply a filter to described here:
http://logging.apache.org/log4j/2.x/manual/filters.html
On 15 March 2016 at 15:08, Robin Coe wrote:
> The current situation for filtering on log level is controlled
The current situation for filtering on log level is controlled by the
LoggerConfig but I'm wondering if that's enough? I'm wondering if it
wouldn't be preferable to associate the log level filter at the appender,
instead/additionally? I realize this is a major change but since a logger
is a one-t
On Tue, Mar 15, 2016 at 9:32 AM, Mikael Ståldal
wrote:
> Perhaps we need to optimize the isEnabled methods?
>
The isEnabled code path for no logging looks pretty lean already. I did
optimize the CompositeFilter to use an array instead of an ArrayList and
avoid creating an iterator on each call.
[
https://issues.apache.org/jira/browse/LOG4J2-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15193049#comment-15193049
]
Mikael Ståldal edited comment on LOG4J2-1116 at 3/15/16 4:37 PM:
--
Error logging is generally the default logging level (it is in log4j as
well as most other frameworks), so it would make sense to support that one
specifically.
On 15 March 2016 at 11:34, Mikael Ståldal wrote:
> It seems a bit arbitrary to have just ErrorLogger and nothing
> corresponding for th
It seems a bit arbitrary to have just ErrorLogger and nothing corresponding
for the other levels.
On Mon, Mar 14, 2016 at 10:00 PM, Gary Gregory
wrote:
> I'm seeing mehtods isTraceEnabled() show up in my profiling sessions.
>
> I'd like to be able to configure Log4j as totally no-op when for use
Perhaps we need to optimize the isEnabled methods?
On Tue, Mar 15, 2016 at 4:07 PM, Gary Gregory
wrote:
> On Tue, Mar 15, 2016 at 3:15 AM, Mikael Ståldal > wrote:
>
>> Is this for testing purposes only?
>>
>
> Well no, I want the code to go as fast as possible under controlled
> conditions in b
Tests work today. Any known commons issue for this? I could probably
reproduce this by setting my system clock to 13 March 2016 or 14 March 2016
after 03:00 sometime.
On 14 March 2016 at 09:50, Matt Sicker wrote:
> Failed tests:
> FixedDateFormatTest.testFormatLong:147
> ABSOLUTE(HH:mm:ss,SSS)
On Tue, Mar 15, 2016 at 3:15 AM, Mikael Ståldal
wrote:
> Is this for testing purposes only?
>
Well no, I want the code to go as fast as possible under controlled
conditions in both tests and production, like when a well tested use case
has been proven to run flawlessly and can be unleashed with
Is this for testing purposes only?
On Tue, Mar 15, 2016 at 10:36 AM, Gary Gregory
wrote:
> On Tue, Mar 15, 2016 at 1:56 AM, Mikael Ståldal > wrote:
>
>> How would you use such a thing?
>>
>
> (1) Run my app performance driver, make sure it works.
> (2) Set logging to "no-op" for all logging to
On Tue, Mar 15, 2016 at 1:56 AM, Mikael Ståldal
wrote:
> How would you use such a thing?
>
(1) Run my app performance driver, make sure it works.
(2) Set logging to "no-op" for all logging to make it go faster (as Remko
describes in theory)
We implement standard APIs (like JDBC) and we call tra
How would you use such a thing?
On Mon, Mar 14, 2016 at 10:00 PM, Gary Gregory
wrote:
> I'm seeing mehtods isTraceEnabled() show up in my profiling sessions.
>
> I'd like to be able to configure Log4j as totally no-op when for use cases
> where performance is all that matters.
>
> I wonder if we
15 matches
Mail list logo
