Ahh. I wasn't aware of that. I'll add future changes at the top.
Nick
On Jul 20, 2013, at 6:44 PM, Ralph Goers wrote:
> Oh - I was expecting to see them at the top since that is where new changes
> are generally added.
>
> Ralph
>
> On Jul 20, 2013, at 4:23 PM, Nick Williams wrote:
>
>> I di
Oh - I was expecting to see them at the top since that is where new changes are
generally added.
Ralph
On Jul 20, 2013, at 4:23 PM, Nick Williams wrote:
> I did update changes.xml. Not sure why you don't see it, but it's there:
>
> http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/src/ch
I did update changes.xml. Not sure why you don't see it, but it's there:
http://svn.apache.org/viewvc/logging/log4j/log4j2/trunk/src/changes/changes.xml?r1=1505102&r2=1505209&diff_format=h
Nick
On Jul 20, 2013, at 6:21 PM, Ralph Goers wrote:
> I didn't see an update to changes.xml. Since this
I didn't see an update to changes.xml. Since this is a breaking change I would
definitely expect to see it in the list of changes.
Ralph
On Jul 20, 2013, at 2:58 PM, Nick Williams wrote:
> The conversion from
> "handleExceptions"/"suppressExceptions"/"isExceptionSuppressed" to
> "ignoreExcep
There are two conversations. The first is on ignore vs. suppress. The
second is on javadocing cleary what the chosen term means.
On Jul 20, 2013 5:42 PM, "Ralph Goers" wrote:
> Well - I saw "hold everything" and then that was followed by "we need
> proper documentation". So I got the impression
Well - I saw "hold everything" and then that was followed by "we need proper
documentation". So I got the impression this was going to be a documentation
change, not a code change (except, I suppose to fix the handleExceptions
variable). But you made the change and it isn't worth the trouble t
Well, first, my main intent for this whole thing was consistency. We have
consistency now.
In the message you reference, I said that I could see how ignoreExceptions
could also be somewhat confusing (due to the dictionary meaning of ignore), but
also said that no matter what we did it would nee
On Jul 20, 2013, at 16:19, Nick Williams
wrote:
Correction below:
On Jul 20, 2013, at 2:38 PM, Nick Williams wrote:
Finally got back to working on this. Noticed two things:
1) On some appenders, ignoreExceptions/suppressExceptions defaults to true.
On other ones it defaults to false. We should
I'm confused. With your message on the 18th I thought you had changed your
mind and agreed that "suppressExceptions" was a better choice than
"ignoreExceptions" since it more accurately describes what is being done.
Ralph
On Jul 20, 2013, at 2:58 PM, Nick Williams wrote:
> The conversion from
On Jul 20, 2013, at 15:39, Nick Williams
wrote:
Finally got back to working on this. Noticed two things:
1) On some appenders, ignoreExceptions/suppressExceptions defaults to true.
On other ones it defaults to false. We should be consistent in this, and
IMO it should default to true. Does anyone
On Jul 20, 2013, at 16:23, Ralph Goers wrote:
Logback always suppresses exceptions. I am not sure about Log4j 1.x without
looking at the code but it may suppress them as well. My first reaction is
to say that suppressing exceptions should be the default but I'd want to
know which Appenders are de
The conversion from
"handleExceptions"/"suppressExceptions"/"isExceptionSuppressed" to
"ignoreExceptions" has been completed.
I still have some work to do to make sure these are being used/abided by
consistently and to make sure that all appenders and managers really do let
exceptions propagat
Yeah - that seems to work.
Ralph
On Jul 20, 2013, at 1:35 PM, Nick Williams wrote:
> You left out the exclamation point.
>
> If value of "junk" is specified and the defaultValue is true then
> (!"false".equalsIgnoreCase("junk") && true) returns true.
>
> However, it should actually be (defaul
You left out the exclamation point.
If value of "junk" is specified and the defaultValue is true then
(!"false".equalsIgnoreCase("junk") && true) returns true.
However, it should actually be (defaultValue && !"false".equalsIgnoreCase(s))
so that it short-circuits it defaultValue is false.
Nick
Why does this not look right to me? If a value of "junk" is specified and the
defaultValue is true then ("false".equalsIgnoreCase("junk") && true) return
false, which is incorrect. It should just return the default value.
Ralph
On Jul 20, 2013, at 1:18 PM, Nick Williams wrote:
> Correction b
On Jul 20, 2013, at 3:22 PM, Ralph Goers wrote:
> Logback always suppresses exceptions. I am not sure about Log4j 1.x without
> looking at the code but it may suppress them as well. My first reaction is to
> say that suppressing exceptions should be the default but I'd want to know
> which App
Logback always suppresses exceptions. I am not sure about Log4j 1.x without
looking at the code but it may suppress them as well. My first reaction is to
say that suppressing exceptions should be the default but I'd want to know
which Appenders are defaulting to not suppress them.
Gary introduc
Correction below:
On Jul 20, 2013, at 2:38 PM, Nick Williams wrote:
> Finally got back to working on this. Noticed two things:
>
> 1) On some appenders, ignoreExceptions/suppressExceptions defaults to true.
> On other ones it defaults to false. We should be consistent in this, and IMO
> it sho
Finally got back to working on this. Noticed two things:
1) On some appenders, ignoreExceptions/suppressExceptions defaults to true. On
other ones it defaults to false. We should be consistent in this, and IMO it
should default to true. Does anyone have any objection to that?
2) o.a.l.l.core.he
On Jul 18, 2013, at 20:28, Paul Benedict wrote:
"Proper documentation" is the key phrase. :-)
Yes! :)
Gary
On Thu, Jul 18, 2013 at 7:25 PM, Nick Williams <
[email protected]> wrote:
> Okay. Hold everything! Lol...
>
> I started working on this change and then realized something
"Proper documentation" is the key phrase. :-)
On Thu, Jul 18, 2013 at 7:25 PM, Nick Williams <
[email protected]> wrote:
> Okay. Hold everything! Lol...
>
> I started working on this change and then realized something. "Suppress"
> means "to forcibly put an end to," "restrain," or "p
Okay. Hold everything! Lol...
I started working on this change and then realized something. "Suppress" means
"to forcibly put an end to," "restrain," or "prevent the development, action,
or expression of." However, "ignore" means "refuse to take notice of or
acknowledge; disregard intentionally
Okay. I'll proceed with the change.
Nick
On Jul 18, 2013, at 2:08 PM, Ralph Goers wrote:
> First, I appreciate having the discussion before a code change like this is
> made. If that had been done I probably would have vetoed it. But this is the
> ASF where everybody gets a single voice and a
First, I appreciate having the discussion before a code change like this is
made. If that had been done I probably would have vetoed it. But this is the
ASF where everybody gets a single voice and a single vote. Although I dislike
this change and the effect it will have on my users I won't veto
Look at AbstractAppender. You will see that it exposes error methods that
Appender implementations can use.
Ralph
On Jul 18, 2013, at 10:56 AM, Nick Williams wrote:
> Well, as long as the Managers always propagate the error back to the
> Appender, then it shouldn't be a problem, right?
>
>
Nice message Nick. I am in agreement with all your points.
Gary
On Thu, Jul 18, 2013 at 2:06 PM, Nick Williams <
[email protected]> wrote:
> Hmmm. So it sounds like we're at an impasse. Everyone except Ralph seems
> to agree to renaming it ignoreExceptions, bug Ralph said the below
Hmmm. So it sounds like we're at an impasse. Everyone except Ralph seems to
agree to renaming it ignoreExceptions, bug Ralph said the below in opposition.
Ralph, can you clarify a little? Are you objecting to just renaming the
XML/JSON attribute (which, really, is the only thing that would break
Well, as long as the Managers always propagate the error back to the Appender,
then it shouldn't be a problem, right?
Where is the ErrorHandler supposed to be used? Is it in each Appender, or is it
used in whatever calls all of the Appenders (and, in that case, why wouldn't
the use be consisten
The ErrorHandler is there primarily to avoid endlessly logging the same error
message every time a log event fails in the appender. Unfortunately, this
isn't used consistently and it is difficult to use from Managers, which is
where most of the errors are going to occur.
Ralph
On Jul 17, 2013
I do not have a problem with renaming handleExceptions to exceptionSuppressed.
I do have a problem with renaming supressExceptions to ignoreExceptions,
primarily because I have a bunch of teams using Log4j 2 in production and they
would have to modify their configurations when they upgrade. Fu
I'll reply when I'm in front of my computer
Sent from my iPad
On Jul 17, 2013, at 7:15 PM, Nick Williams
wrote:
> I'd like to get Paul's and Ralph's feedback before I make this change.
>
> Nick
>
> On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
>
>> On Jul 17, 2013, at 20:11, Nick William
I am good with #ignoreExceptions()
On Wed, Jul 17, 2013 at 9:15 PM, Nick Williams <
[email protected]> wrote:
> I'd like to get Paul's and Ralph's feedback before I make this change.
>
> Nick
>
> On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
>
> > On Jul 17, 2013, at 20:11, Nick W
I'd like to get Paul's and Ralph's feedback before I make this change.
Nick
On Jul 17, 2013, at 7:28 PM, Gary Gregory wrote:
> On Jul 17, 2013, at 20:11, Nick Williams
> wrote:
>
>> So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that,
>> too.
>
> Yep, that's what I mea
On Jul 17, 2013, at 20:11, Nick Williams wrote:
> So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that,
> too.
Yep, that's what I meant.
Gary
>
> Nick
>
> On Jul 17, 2013, at 7:04 PM, Gary Gregory wrote:
>
>> I think I like the "ignoreExceptions" variation.
>>
>> Gary
>>
>
So Appender#ignoreExceptions() and XML/JSON ignoreExceptions? I like that, too.
Nick
On Jul 17, 2013, at 7:04 PM, Gary Gregory wrote:
> I think I like the "ignoreExceptions" variation.
>
> Gary
>
> On Jul 17, 2013, at 18:39, Nick Williams
> wrote:
>
>> ignoreExceptions
>
>
I think I like the "ignoreExceptions" variation.
Gary
On Jul 17, 2013, at 18:39, Nick Williams wrote:
> ignoreExceptions
-
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: log4j
Okay. So there are two things we need to think about here:
1) The Appender interface contains a method named isExceptionSuppressed(). I've
never liked that name anyway (the grammar is awkward). Do we want to rename
this method? Some ideas: areExceptionsIgnored(), shouldIgnoreExceptions(),
ignor
Aren't we really just talking about ignoring exceptions? If so, "ignore" is
much better than "suppressing" for the reason I raised.
On Wed, Jul 17, 2013 at 5:10 PM, Gary Gregory wrote:
> On Wed, Jul 17, 2013 at 5:48 PM, Paul Benedict wrote:
>
>> The phrase "suppressed exception" actually means s
On Wed, Jul 17, 2013 at 5:48 PM, Paul Benedict wrote:
> The phrase "suppressed exception" actually means something specific in the
> JDK. Are you okay with using the same terminology?
>
> http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
>
This is confusing IMO, w
I think it's pretty clear here that Log4j suppressing appender exceptions and
JDK Suppressed Exceptions are not the same thing. I don't think it's something
that we need to worry about, and changing the name to something else (what?)
would require a much bigger refactor (and would be an API-alte
The phrase "suppressed exception" actually means something specific in the
JDK. Are you okay with using the same terminology?
http://docs.oracle.com/javase/tutorial/essential/exceptions/tryResourceClose.html
On Wed, Jul 17, 2013 at 4:42 PM, Nick Williams <
[email protected]> wrote:
>
Appender specifies a method, isExceptionSuppressed(), which indicates whether
exceptions thrown while appending events should be suppressed (logged instead
of re-thrown).
AbstractAppender implements this method with a private handleExceptions field
and a handleExceptions constructor argument. i
42 matches
Mail list logo
