>>>>
>>>> Gary
>>>>
>>>>
>>>> On Fri, Jan 24, 2014 at 3:56 PM, Christian Grobmeier <
>>>> grobme...@gmail.com> wrote:
>>>> On 24 Jan 2014, at 21:47, Paul Benedict wrote:
>>>>
>>>> We should ensu
ser guide explain
>>> recommended usages for these. Mailing lists are for the most die-hard
>>> development fans. :-)
>>>
>>> +1
>>>
>>> Recommendations and documentation are/is absolutely necessary.
>>>
>>> I will happily go thro
been descriptions of what the levels are for... see Ralph
'
message, many of mine and others. I know it can be tedious to go back
through various threads but the info is there. If you want more info,
feel
free to ask ;)
Gary
Original message ----
From: Christian Grobmeier
Date
>
> There have been descriptions of what the levels are for... see Ralph '
> message, many of mine and others. I know it can be tedious to go back
> through various threads but the info is there. If you want more info, feel
> free to ask ;)
>
> Gary
>
>
> ---
gt;
>>
>>
>>>
>>> On Fri, Jan 24, 2014 at 2:38 PM, Gary Gregory >> >wrote:
>>>
>>> There have been descriptions of what the levels are for... see Ralph '
>>>> message, many of mine and others. I know it can be tedious to go back
&
many of mine and others. I know it can be tedious to go back
>>> through various threads but the info is there. If you want more info,
>>> feel
>>> free to ask ;)
>>>
>>> Gary
>>>
>>>
>>> Original message
>>> From:
thing (as silly as it sounds)
>
>
>> Gary
>>
>> -------- Original message
>> From: Paul Benedict
>> Date:01/24/2014 15:47 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Re: Levels added in revision 1560602
>>
>> We should
I would not be in favor of removing FATAL for no other reason than it makes
mapping levels from SLF4J and Commons Logging easy.
Ralph
On Jan 24, 2014, at 12:20 PM, Scott Deboy wrote:
> I think the 'levels=severity' model broke down a bit when we added
> TRACE, and FATAL is never used, so I thi
thing (as silly as it sounds)
Gary
Original message
From: Paul Benedict
Date:01/24/2014 15:47 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Levels added in revision 1560602
We should ensure that both the Javadocs and the user guide explain
recommended usages for these
more info,
feel
free to ask ;)
Gary
Original message
From: Christian Grobmeier
Date:01/24/2014 14:20 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Levels added in revision 1560602
What I miss in this discussion are actually good examples of what the
(new) log levels ar
t: Re: Levels added in revision 1560602
What I miss in this discussion are actually good examples of what the
(new) log levels are intended for.
In example, Gary mentioned he is on a wireshark level with "trace".
That's fine, because it would give some idea when to use verbose (ma
GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Levels added in revision 1560602
>
> What I miss in this discussion are actually good examples of what the
> (new) log levels are intended for.
>
> In example, Gary mentioned he is on a wireshark level with "trace"
stian Grobmeier
Date:01/24/2014 14:20 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Levels added in revision 1560602
What I miss in this discussion are actually good examples of what the
(new) log levels are intended for.
In example, Gary mentioned he is on a wireshark level with "trac
It all depends on what you think "severity" means. If you think severity is
simply for severity of errors, then yes, it's broken. However, I look at
severity to mean the intensity of the message, which I think fits just fine
with the levels we have. Errors are mean to be intense messages; traces no
I think the 'levels=severity' model broke down a bit when we added
TRACE, and FATAL is never used, so I think it's reasonable to say
there isn't a strict severity we can use even today - which is why we
have so few levels (trying to stick to the severity model).
By the way, we should remove FATAL,
I agree. When anyone starts talking about "types" of informational messages
or "types" of debug information, those should be distinguished with markers.
My mental model is this:
levels = severity
markers = kinds/types
On Fri, Jan 24, 2014 at 1:57 PM, Ralph Goers wrote:
> I would tend to agree
I would tend to agree with the way you are using them.
I do see a a need for DIAG (or whatever other name you like). We don’t tend to
use a lot of info messages as those are just nice to know things but probably
wouldn’t aid a lot in problem diagnosis. OTOH, DEBUG tends to log everything
exce
This is how I use today's levels:
TRACE - entry and exit of methods, raw and extremely detailed data dumps
DEBUG - status and configuration to view while application is running for
developer inspection purposes
INFO - application state changes that an operator may need to know to
inspect health of
What I miss in this discussion are actually good examples of what the
(new) log levels are intended for.
In example, Gary mentioned he is on a wireshark level with "trace".
That's fine, because it would give some idea when to use verbose (maybe
entering method).
Maybe I missed it when what I
On Fri, Jan 24, 2014 at 12:15 PM, Remko Popma wrote:
> I'm not questioning your experience, and I believe you when you say that
> the proposed levels would be a perfect match for your current work
> environment.
>
> However, out of the eight people that participated in the discussion on
> adding
To be fair, I think we represent a reasonable fraction of the
users..some won't touch new predefined levels, some will use it -
that's the reason for adding it - we hit a significant portion of use
cases with small additional number of built-in levels.
The two solutions don't provide the same thin
I'm not questioning your experience, and I believe you when you say that
the proposed levels would be a perfect match for your current work
environment.
However, out of the eight people that participated in the discussion on
adding levels, four expressed strong reservations about adding pre-define
On Thu, Jan 23, 2014 at 10:18 PM, Ralph Goers wrote:
> Gary, although Remko hasn’t said it I think he is implying that he is
> vetoing the code commit. Unfortunately, unless you can convince Remko
> otherwise you are going to have to revert the commit.
>
> Remko, if that isn’t your intention then
Yes, sorry for the extra work, but please revert the commit.
On Friday, January 24, 2014, Ralph Goers wrote:
> Gary, although Remko hasn’t said it I think he is implying that he is
> vetoing the code commit. Unfortunately, unless you can convince Remko
> otherwise you are going to have to rever
Gary, although Remko hasn’t said it I think he is implying that he is vetoing
the code commit. Unfortunately, unless you can convince Remko otherwise you are
going to have to revert the commit.
Remko, if that isn’t your intention then please say so as it will save Gary a
bunch of work.
Ralph
To clarify my position on the proposed DIAG, VERBOSE, NOTICE log levels: I
don't think these levels should be added to the Log4J API.
Here is my thinking:
1. The current five levels are a de facto. standard. (For example, they
match the SLF4J levels.) They are sufficient for the vast majority of
I'm fine with Nick's proposal to have two separate votes.
Remko
On Friday, January 24, 2014, Nick Williams
wrote:
> There has obviously been some serious discussion about these topics. We're
> not going to come to a total agreement on this. I propose:
>
> - We have a committers-only vote in the
There has obviously been some serious discussion about these topics. We're not
going to come to a total agreement on this. I propose:
- We have a committers-only vote in the "Enums and Custom Levels" thread on
whether to make Level an extensible enum.
- AFTER having that vote, we have a committe
On Thu, Jan 23, 2014 at 11:54 AM, Scott Deboy wrote:
> We don't need to scuttle the new levels to support extensible levels.
>
Of course. The two things are not technically related. That's not what this
is about, though. Since there are camps for and against the new levels, I
was hoping the "ex
These are two separate features.
>>
>> Gary
>>
>>
>> ---- Original message ----
>> From: Scott Deboy
>> Date:01/23/2014 11:49 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Re: Levels added in revision 1560602
>>
>>
T-05:00)
> To: Log4J Developers List
> Subject: Re: Levels added in revision 1560602
>
> I don't think the two have to be mutually exclusive - we can enhance
> 'custom level' support via a new mechanism and add built-in support
> for the new levels as well.
>
> I pe
Well said Scott.
These are two separate features.
Gary
Original message
From: Scott Deboy
Date:01/23/2014 11:49 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Levels added in revision 1560602
I don't think the two have to be mutually exclusive - we can en
I don't think the two have to be mutually exclusive - we can enhance
'custom level' support via a new mechanism and add built-in support
for the new levels as well.
I personally don't think they're confusing, as folks have mentioned,
httpd uses them.
I used to think of levels as 'severities', but
Remko, are you saying that if we make the changes proposed in the other thread
that we should not add any of these levels to the new Level class?
Ralph
On Jan 23, 2014, at 1:22 AM, Remko Popma wrote:
> Gary,
>
> Would you mind rolling back the changes you made in revision 1560602 (and
> pe
Gary,
Would you mind rolling back the changes you made in revision 1560602 (and
perhaps r1560356)?
This change added DIAG, VERBOSE, NOTICE log levels to many files.
I don't think we all agreed on that approach and we have some promising
ideas for an alternative solution that should satisfy everyon
35 matches
Mail list logo
