>>>
>>>> On Feb 3, 2014, at 3:46 PM, Matt Sicker wrote:
>>>>
>>>> Plus, if we're really keen on OSGi support, note that OSGi assumes
>>>> version numbers follow the semantic versioning scheme. Producers use an API
>>>> like [1.
ot;beta" from a community perspective.
>>> I also don't don't think that we are beta anymore and it would
>>> be misleading for the community. In fact, having a RC would
>>> show we are close before.
>>>
>>> You are more the beta guy whe
leading for the community. In fact, having a RC would
show we are close before.
You are more the beta guy where I am usually more into GA, so can we
find a compromise on RC?
Sure, you can put whatever label it, but I think there should be as
many
releases as needed until we have an RC-n to
ty. In fact, having a RC would
> show we are close before.
>
> You are more the beta guy where I am usually more into GA, so can we
> find a compromise on RC?
>
Sure, you can put whatever label it, but I think there should be as many
releases as needed until we have an RC-n to GA with
y where I am usually more into GA, so can we
find a compromise on RC?
Cheers
Christian
On 7 Feb 2014, at 22:07, Gary Gregory wrote:
I think the next release should be an RC (or beta), not the GA. There
are
just too many changes since beta-9 IMO.
Ideally, there should only be minor fixes from RC t
I think the next release should be an RC (or beta), not the GA. There are
just too many changes since beta-9 IMO.
Ideally, there should only be minor fixes from RC to GA.
Gary
On Fri, Feb 7, 2014 at 4:03 PM, Christian Grobmeier wrote:
> Let me do the package rename from couch to couchdb.
lity without a major
release change (and accompanying package and Maven coordinate
changes).
Gary
On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma
wrote:
How about an RC now (after showstoppers are fixed),
then the GA release say one month later?
Keep in mind we can still have bugix releases in 2
hout a major
>>> release change (and accompanying package and Maven coordinate changes).
>>>
>>> Gary
>>>
>>>
>>> On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma
>>> wrote:
>>> How about an RC now (after showstoppers are fixed),
&g
follow the semantic versioning scheme. Producers use an API
>>> like [1.1, 1.2), whereas consumers use an API like [1.1, 2.0). Yes, those
>>> are half-open intervals, and yes, that is the official notation. :)
>>>
>>>
>>> On 3 February 2014 15:41, Christian
t;>>>> N
>>>>>
>>>>>> On Feb 3, 2014, at 3:46 PM, Matt Sicker wrote:
>>>>>>
>>>>>> Plus, if we're really keen on OSGi support, note that OSGi assumes
>>>>>> version numbers follow the semantic
gt; numbers follow the semantic versioning scheme. Producers use an API like
>>> [1.1, 1.2), whereas consumers use an API like [1.1, 2.0). Yes, those are
>>> half-open intervals, and yes, that is the official notation. :)
>>>
>>>
>>> On 3 February 20
tation. :)
>>
>>
>> On 3 February 2014 15:41, Christian Grobmeier wrote:
>>
>>> On 3 Feb 2014, at 22:14, Matt Sicker wrote:
>>>
>>> > I like 2.0.0 because semver.org etc., although as long as it's not a
>>> dumb
>>> >
those are
>> half-open intervals, and yes, that is the official notation. :)
>>
>>
>> On 3 February 2014 15:41, Christian Grobmeier wrote:
>> On 3 Feb 2014, at 22:14, Matt Sicker wrote:
>>
>> > I like 2.0.0 because semver.org etc., although as lo
e are
> half-open intervals, and yes, that is the official notation. :)
>
>
> On 3 February 2014 15:41, Christian Grobmeier wrote:
>
>> On 3 Feb 2014, at 22:14, Matt Sicker wrote:
>>
>> > I like 2.0.0 because semver.org etc., although as long as it's not a
>&
intervals, and yes, that is the official notation. :)
>
>
> On 3 February 2014 15:41, Christian Grobmeier wrote:
> On 3 Feb 2014, at 22:14, Matt Sicker wrote:
>
> > I like 2.0.0 because semver.org etc., although as long as it's not a dumb
> > version number like GA o
On 3 February 2014 15:41, Christian Grobmeier wrote:
> On 3 Feb 2014, at 22:14, Matt Sicker wrote:
>
> > I like 2.0.0 because semver.org etc., although as long as it's not a
> dumb
> > version number like GA or RELEASE or Final, I'm happy with it.
>
> Sticking with s
On 3 Feb 2014, at 22:14, Matt Sicker wrote:
> I like 2.0.0 because semver.org etc., although as long as it's not a dumb
> version number like GA or RELEASE or Final, I'm happy with it.
Sticking with semver might be a good idea. Its a language many understand
and we should try to
I like 2.0.0 because semver.org etc., although as long as it's not a dumb
version number like GA or RELEASE or Final, I'm happy with it.
On 3 February 2014 07:07, Gary Gregory wrote:
> Keep it simple: 2.0.
>
> Gary
>
>
> Original message
> From
Keep it simple: 2.0.
Gary
Original message
From: Christian Grobmeier
Date:02/03/2014 05:12 (GMT-05:00)
To: Log4J Developers List
Subject: Re: What will the GA version number be?
Also 2.0 or 2.0.0 for me
On 3 Feb 2014, at 7:41, Ralph Goers wrote:
> I had thought
>> be 2.0 but 2.0.0 would be fine. Since we will eventually release a 2.0.1, I
>> propose that we keep the version numbers the same consistent length (and
>> follow a convention most other OSS projects use), and release GA as "2.0.0"
>> without any other quali
on most other OSS projects use), and release GA as "2.0.0"
> without any other qualifiers (no GA, no Final, etc.).
>
> All in favor? :-)
>
> N
>
> On Feb 3, 2014, at 4:12 AM, Christian Grobmeier wrote:
>
> > Also 2.0 or 2.0.0 for me
> >
> > On 3
I've seen some people say 2.0.0 and some people say they figured it would be
2.0 but 2.0.0 would be fine. Since we will eventually release a 2.0.1, I
propose that we keep the version numbers the same consistent length (and follow
a convention most other OSS projects use), and release
it to say Level was
extendable!), and I need to know what the Maven artifact GA version
number will be. I print the new Maven artifacts used in each chapter
on the first page of the chapter as a guide to the user. Log4j is the
only library I'm using that isn't yet GA. I want to be sure
need to know what the Maven artifact GA version number will be. I print the
> new Maven artifacts used in each chapter on the first page of the chapter as
> a guide to the user. Log4j is the only library I'm using that isn't yet GA. I
> want to be sure the version numbers I&#x
-binding. :-)
>
>
> On Sun, Feb 2, 2014 at 10:59 PM, Nick Williams <
> nicho...@nicholaswilliams.net
> > wrote:
>
>> I'm finalizing the logging chapter of my book to send to the printers
>> Wednesday (I'm so glad I got to correct it to say Level was extendable!),
&g
extendable!),
> and I need to know what the Maven artifact GA version number will be. I
> print the new Maven artifacts used in each chapter on the first page of the
> chapter as a guide to the user. Log4j is the only library I'm using that
> isn't yet GA. I want to be sure th
I'm finalizing the logging chapter of my book to send to the printers Wednesday
(I'm so glad I got to correct it to say Level was extendable!), and I need to
know what the Maven artifact GA version number will be. I print the new Maven
artifacts used in each chapter on the first p
not break binary compatibility without a major
release change (and accompanying package and Maven coordinate
changes).
Gary
On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma
wrote:
How about an RC now (after showstoppers are fixed),
then the GA release say one month later?
Keep in mind we can
;
> Gary
>
>
> On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma wrote:
> How about an RC now (after showstoppers are fixed),
> then the GA release say one month later?
>
> Keep in mind we can still have bugix releases in 2.0.1, etc, and even API
> changes in 2.1 etc...
>
That makes sense. Thanks Gary and Nick for clarifying my statement.
On Tue, Jan 28, 2014 at 7:21 AM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> I'm fine with an RC this week and a GA one month later. I think that's
> perfect. I agree with Remko that we can h
I'm fine with an RC this week and a GA one month later. I think that's perfect.
I agree with Remko that we can have API /additions/ in 2.1 (or, at any time,
IMO), but I agree with Gary that we can't have binary compatibility-breaking
changes until 3.0.
N
On Jan 27, 2014, a
IMO: We cannot/should not break binary compatibility without a major
release change (and accompanying package and Maven coordinate changes).
Gary
On Mon, Jan 27, 2014 at 4:59 PM, Remko Popma wrote:
> How about an RC now (after showstoppers are fixed),
> then the GA release say one month
How about an RC now (after showstoppers are fixed),
then the GA release say one month later?
Keep in mind we can still have bugix releases in 2.0.1, etc, and even API
changes in 2.1 etc...
On Tuesday, January 28, 2014, Matt Sicker wrote:
> I agree on putting out an RC release. I think it mi
I agree on putting out an RC release. I think it might help spur some 3rd
party development to integrate with the new version.
On 27 January 2014 12:37, Gary Gregory wrote:
> So, yes, the new level API needs to go through a non-GA release. Aside
> from that, I am behind in my Log4j2 ho
So, yes, the new level API needs to go through a non-GA release. Aside from
that, I am behind in my Log4j2 homework to see how much work it will be to
convert our Log4j1 code and extensions to v2. But that's just an issue on
my end that should not hold up everyone else.
I've been
If people really thing that another non-GA release is necessary, please
label it RC.
Beta sounds as log4j2 is absolutely not ready but this isn't the case.
At least with a RC we show some confidence in what we do.
As additions are easier to make then removals, I would even sacrifice
some
Due to the API change I can agree with having another beta or an RC but the
reason I asked about GA is that I am not aware of very many showstopper issues
that need to be addressed. I am sensing that you have a real reluctance to
have Log4j 2 released as GA and I am trying to understand what
ppender?
>
> I am more concerned about all the issues people seem to have in servlet
> environments.
>
>
> Gary
>
>
> On Mon, Jan 27, 2014 at 7:22 AM, Nick Williams <
> nicho...@nicholaswilliams.net> wrote:
>
>> I wouldn't necessarily vote against a G
ering one bundle
(jar) per appender?
I am more concerned about all the issues people seem to have in servlet
environments.
Gary
On Mon, Jan 27, 2014 at 7:22 AM, Nick Williams <
nicho...@nicholaswilliams.net> wrote:
> I wouldn't necessarily vote against a GA, but given t
I wouldn't necessarily vote against a GA, but given that we just MAJORLY
overhauled Level, I think a brief RC is in order. It would be a shame if
someone found a problem with Level a week after GA that caused us to need to
change the API to fix it.
Nick
On Jan 27, 2014, at 12:51 AM,
I'd like to fix LOG4J-412 and 448, but neither of them are showstoppers IMHO
.
Remko
On Monday, January 27, 2014, Ralph Goers wrote:
> Since we are having good discussions I would also like to find out what
> are blockers to a GA release. My list includes:
> 1. The fix Nick is
Since we are having good discussions I would also like to find out what are
blockers to a GA release. My list includes:
1. The fix Nick is working on to allow Servlet initialization to be disabled
from automatically happening in a 3.0 container.
2. Support for programmatic configuration of
ATOM QUARK STRING?
Original message
From: Nick Williams
Date:01/23/2014 13:44 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
A ZOMBIE_APOCALYPSE Level would be EPIC! ;-)
N
On Jan 23, 2014, at 1:31 AM, Christian Grobmeier wrote
that is not as high as APOCALYPSE right?
>>
>> Gary
>>
>> Original message
>> From: Matt Sicker
>> Date:01/22/2014 21:43 (GMT-05:00)
>> To: Log4J Developers List
>> Subject: Re: Web Issues, Logging Levels, and GA
>>
>> I
Yes yes now we are getting somwhere... UNICORN_AND_RAINBOWS!
G
Original message
From: Christian Grobmeier
Date:01/23/2014 06:31 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
Maybe:
ZOMBIE_APOCALYPSE > APOCALYPSE > CATAS
Developers List
Subject: Re: Web Issues, Logging Levels, and GA
I think we should use the CATASTROPHE logging level.
On 22 January 2014 17:38, Remko Popma wrote:
Looks like we're in a tricky spot...
I count four people in favor of keeping the current levels who don't
want to add leve
But that is not as high as APOCALYPSE right?
Gary
Original message
From: Matt Sicker
Date:01/22/2014 21:43 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
I think we should use the CATASTROPHE logging level.
On 22 January 2014 17
Hi, there is no doubt that the proposal is cool. Can we discuss this in a fresh
separate thread?
Gary
Original message
From: Paul Benedict
Date:01/22/2014 20:52 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
Agreed. This is not
dly.
>
> I have have lots of buttons, knobs and settings on my sound system that I
> do not use, just like I do not use all the methods in all the classes in
> the JRE...
>
> Gary
>
>
> Original message
> From: Remko Popma
> Date:01/22/2014 18:38 (G
I think we should use the CATASTROPHE logging level.
On 22 January 2014 17:38, Remko Popma wrote:
> Looks like we're in a tricky spot...
>
> I count four people in favor of keeping the current levels who don't want
> to add levels (Paul, Christian, Matt and myself),
> two people who really want
iginal message
> From: Remko Popma
> Date:01/22/2014 18:38 (GMT-05:00)
> To: Log4J Developers List
> Subject: Re: Web Issues, Logging Levels, and GA
>
> Looks like we're in a tricky spot...
>
> I count four people in favor of keeping the current levels who don&#
GA
Looks like we're in a tricky spot...
I count four people in favor of keeping the current levels who don't want to
add levels (Paul, Christian, Matt and myself),
two people who really want to add levels (Gary and Nick)
and two people who are not pushing for new levels but don't
Looks like we're in a tricky spot...
I count four people in favor of keeping the current levels who don't want
to add levels (Paul, Christian, Matt and myself),
two people who really want to add levels (Gary and Nick)
and two people who are not pushing for new levels but don't mind the change
(Sco
I use trace for wire level hex dumps. Think Wireshark.
Gary
Original message
From: Christian Grobmeier
Date:01/22/2014 15:12 (GMT-05:00)
To: Log4J Developers List
Subject: Re: Web Issues, Logging Levels, and GA
Jumping in late, sorry. I have read all messages around
Yes, I know. It is a big change but it is also one that's necessary to
support custom logging levels that are enums.
On Wed, Jan 22, 2014 at 3:04 PM, Ralph Goers wrote:
> Paul,
>
> Take a look at the Logger, LoggerConfig and Lo4jLogEvent classes and
> LogEvent interface in log4j-core. Then look
Paul,
Take a look at the Logger, LoggerConfig and Lo4jLogEvent classes and LogEvent
interface in log4j-core. Then look at the Filter interface and the
ThresholdFilter implementation. Looking at those classes you will see that the
change you are proposing has a much larger impact than what you
Ralph,
Perhaps you're misunderstanding or I was unclear (let's say it's the
latter).
The interface is only so you can allow custom log levels as an enum. The
client code could still use the enums you provided today. All that's
changing is the API signatures to accept the interface -- which
conven
Jumping in late, sorry. I have read all messages around this now
(hopefully) and I am still unsure why we actually need new log levels.
Personally I don't see much difference between trace and verbose.
Honestly the people I spoke to are usually using debug. I don't know
many people who actually
I am fine with DIAG. I had always thought INFO was the abbreviation for
INFORMATIONAL, which is way too long.
Ralph
> On Jan 22, 2014, at 6:21 AM, Gary Gregory wrote:
>
>> On Wed, Jan 22, 2014 at 1:33 AM, Ralph Goers
>> wrote:
>> First, I assume you meant to code “implements LogLevelStrengt
On Wed, Jan 22, 2014 at 1:33 AM, Ralph Goers wrote:
> First, I assume you meant to code “implements LogLevelStrength” instead of
> “extends LogLevelStrength” since an enum already implicitly extends Enum
> and a Class (or Enum) can’t extend an Interface.
>
> Second, doing this would mean that the
First, I assume you meant to code “implements LogLevelStrength” instead of
“extends LogLevelStrength” since an enum already implicitly extends Enum and a
Class (or Enum) can’t extend an Interface.
Second, doing this would mean that the Log4j 2 core would have to be modified
to never use the Le
Or if you really want to get fancy (!!!), don't make the log4j API accept
an Level, but an interface that each logging level Enum object implements.
Then programmers can use enums. Example:
public interface LogLevelStrength {
int getStrength();
}
public enum Level extends LogLevelStrength {
It won't be possible with an enum, yes, but we should have a way to allow
extensions. For example, if we publically document the integer level of the
enums (separated by 100), then we can provide an overload that accepts an
integer. That's how you can allow people to slide in their extensions.
Phil
On Tue, Jan 21, 2014 at 11:33 AM, Paul Benedict wrote:
> On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers
> wrote:
>
>>
>> I tend to agree that there is ambiguity between TRACE and VERBOSE, but I
>> have no problem adding it if it means end users will have more flexibility
>> with little cost.
>>
>>
On Tue, Jan 21, 2014 at 10:25 AM, Ralph Goers wrote:
>
> I tend to agree that there is ambiguity between TRACE and VERBOSE, but I
> have no problem adding it if it means end users will have more flexibility
> with little cost.
>
>
I think this is meaningless flexibility. It smells of adding a feat
>
> I tend to agree that there is ambiguity between TRACE and VERBOSE, but I
> have no problem adding it if it means end users will have more flexibility
> with little cost.
>
> Whatever we do it needs to be done now before a GA release. The Levels
> are all defined with i
ere is ambiguity between TRACE and VERBOSE, but I
> have no problem adding it if it means end users will have more flexibility
> with little cost.
>
> Whatever we do it needs to be done now before a GA release. The Levels
> are all defined with integer values that will have to change if
will have more flexibility with
little cost.
Whatever we do it needs to be done now before a GA release. The Levels are all
defined with integer values that will have to change if new levels are inserted
thus breaking compatibility (everything using Log4j 2 in the system will need
to be
gt;
>>>>>>>> I see TRACE as method entry and exit type of logging, *very* *low*
>>>>>>>> level stuff.
>>>>>>>>
>>>>>>>> We could also have both (ducking for projectiles):
>>>>>>>>
&g
RACE
>>>>>>>>>>
>>>>>>>>>> Gary
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers
>>>>>>>&g
; TRACE
>>>>>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com> wrote:
>>>
> I'm much in favor of keeping the existing levels. We can make markers easier
> to use and document how people can use them to create whatever custom level
> they want. I think this is a much more powerful solution than modifying the
> existing levels.
How about making it as easy to filter by
>>>> struggling with how that is any different than TRACE. I guess the idea
>>>>>>> is that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>>>> detailed debug messages? I suppose I can go along with that a
pe of logging, *very* *low*
>>>>>>>> level stuff.
>>>>>>>>
>>>>>>>> We could also have both (ducking for projectiles):
>>>>>>>>
>>>>>>>> INFO
>>>>>>>> V
gt;>>>
>>>>>>> Gary
>>>>>>>
>>>>>>>
>>>>>>> On Sat, Jan 18, 2014 at 12:47 PM, Ralph Goers <
>>>>>>> ralph.go...@dslextreme.com> wrote:
>>>>>>>
>>>&
;>> On Jan 18, 2014, at 9:44 AM, Ralph Goers
>>>>>>> wrote:
>>>>>>>
>>>>>>> I understand the need for CONFIG. However it isn’t clear to me
>>>>>>> whether it belongs between INFO and WARN or DEBUG and INFO.
8, 2014, at 9:44 AM, Ralph Goers
>>>>>>> wrote:
>>>>>>>
>>>>>>> I understand the need for CONFIG. However it isn’t clear to me
>>>>>>> whether it belongs between INFO and WARN or DEBUG and INFO. That
gt;>>> messages as well. Due to that, it would make more sense to me to make a
>>>>>> CONFIG marker.
>>>>>>
>>>>>> I don’t really understand the point of FINE or FINER.
>>>>>>
>>>>>> On the other hand, VER
>>>>> I don’t really understand the point of FINE or FINER.
>>>>>
>>>>> On the other hand, VERBOSE does make a bit more sense, but I’m
>>>>> struggling with how that is any different than TRACE. I guess the idea is
>>>>> tha
gt;>>> detailed debug messages? I suppose I can go along with that argument, but
>>>> again one could just as easily create a VERBOSE marker and attach it to
>>>> either TRACE or DEBUG. I guess I wouldn’t object if VERBOSE was added as a
>>>> Level but I’m n
>>> On Jan 18, 2014, at 7:08 AM, Remko Popma wrote:
>>>
>>> I've always liked Ralph's argument that Markers give users much more
>>> flexibility than any predefined Levels.
>>> I would prefer to stick to the log4j/slf4j level names.
>>>
&
any predefined Levels.
>>> I would prefer to stick to the log4j/slf4j level names.
>>>
>>>
>>> On Sat, Jan 18, 2014 at 10:32 PM, Gary Gregory
>>> wrote:
>>>
>>>> Interesting, I have been wanting a VERBOSE level better INFO and DEBUG
On Sat, Jan 18, 2014 at 3:30 PM, Nicholas Williams <
nicho...@nicholaswilliams.net> wrote:
> I explained in the email why CONFIG > INFO. Not sure I can explain it any
> better. :-/
>
I just thought of a different name for a level name b/w WARN and INFO:
NOTICE.
I do not find having another level
;>>>> That doesn’t necessarily imply that you would then want to see all INFO
>>>>>> messages as well. Due to that, it would make more sense to me to make a
>>>>>> CONFIG marker.
>>>>>>
>>>>>> I don’t really unde
;>> is that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>>> detailed debug messages? I suppose I can go along with that argument,
>>>>>> but again one could just as easily create a VERBOSE marker and attach it
>>>>>&g
w that is any different than TRACE. I guess the idea is
>>>>> that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>> detailed debug messages? I suppose I can go along with that argument, but
>>>>> again one could just as easily create
I guess the idea is
>>>>> that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>> detailed debug messages? I suppose I can go along with that argument, but
>>>>> again one could just as easily create a VERBOSE marker and attach it to
>
>>>>>> That doesn’t necessarily imply that you would then want to see all INFO
>>>>>> messages as well. Due to that, it would make more sense to me to make a
>>>>>> CONFIG marker.
>>>>>>
>>>>>> I don’t real
gt;>>> either TRACE or DEBUG. I guess I wouldn’t object if VERBOSE was added as a
>>>> Level but I’m not really convinced it is necessary either.
>>>>
>>>> Ralph
>>>>
>>>>
>>>>
>>>> On Jan 18, 2014, at 7:08 AM,
>>>>
>>>>
>>>> On Jan 18, 2014, at 7:08 AM, Remko Popma wrote:
>>>>
>>>> I've always liked Ralph's argument that Markers give users much more
>>>> flexibility than any predefined Levels.
>>>> I would prefer
27;s argument that Markers give users much more
>>> flexibility than any predefined Levels.
>>> I would prefer to stick to the log4j/slf4j level names.
>>>
>>>
>>> On Sat, Jan 18, 2014 at 10:32 PM, Gary Gregory
>>> wrote:
>>>
>>
t TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>> detailed debug messages? I suppose I can go along with that argument, but
>>>>> again one could just as easily create a VERBOSE marker and attach it to
>>>>> either TRACE or DEBUG. I
E does make a bit more sense, but I’m
>>>>>> struggling with how that is any different than TRACE. I guess the idea
>>>>>> is that TRACE is for control flow (entry, exit) and VERBOSE is for more
>>>>>> detailed debug messages? I suppose I can go along with that
y either.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>> On Jan 18, 2014, at 7:08 AM, Remko Popma wrote:
>>>>>
>>>>>> I've always liked Ralph's argument that Markers g
ed as a
>>>>> Level but I’m not really convinced it is necessary either.
>>>>>
>>>>> Ralph
>>>>>
>>>>>
>>>>>
>>>>> On Jan 18, 2014, at 7:08 AM, Remko Popma wrote:
>>>>>
>>>>
08 AM, Remko Popma wrote:
>>>>
>>>> I've always liked Ralph's argument that Markers give users much more
>>>> flexibility than any predefined Levels.
>>>> I would prefer to stick to the log4j/slf4j level names.
>>>>
>>>&
t;>>> it to either TRACE or DEBUG. I guess I wouldn’t object if VERBOSE was
>>>>>>> added as a Level but I’m not really convinced it is necessary either.
>>>>>>>
>>>>>>> Ralph
>>>>>>>
>>>>>>
gt;>
>>>> Interesting, I have been wanting a VERBOSE level better INFO and DEBUG.
>>>>
>>>> See
>>>> http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201310.mbox/%3CCACZkXPxNwYbn__CbXUqFhC7e3Q=kee94j+udhe8+6jiubcz...@mail.gmail.com%3
;
>>>> See
>>>> http://mail-archives.apache.org/mod_mbox/logging-log4j-dev/201310.mbox/%3CCACZkXPxNwYbn__CbXUqFhC7e3Q=kee94j+udhe8+6jiubcz...@mail.gmail.com%3E
>>>>
>>>> You'll have to dig a little in that ref to find my proposal, sorry
ave to dig a little in that ref to find my proposal, sorry I'm
>>> on my phone ATM.
>>>
>>> It sounds like we see logging configuration messages differently though.
>>> I do not like the name CONFIG because it does not sound like a level to me.
>>>
1 - 100 of 146 matches
Mail list logo
