You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by Dennis Cook <de...@cook-mail.net> on 2003/11/01 17:53:49 UTC
Re: Rationale for TRACE-level/priority.
On Friday, October 31, 2003, at 11:10 AM, Ceki Gülcü wrote:
> At 08:29 AM 10/31/2003 -0800, Dennis Cook wrote:
>
>>> 2) make a personal issue out of this topic
>>
>> Since all use of any level is subjective, a refusal to add a TRACE
>> level, that seems to be a highly request feature, can only be seen as
>> a "personal" issue already. It has already been established that
>> domains will not replace levels, so for those that may not have the
>> option of moving to the use of domains, a TRACE level is still an
>> unmet need.
>
> How was it established that domains will not replace levels?
Maybe that was just an assumption, on my part, but I did ask in a
previous message if domains were going to replace levels, Also the
release number, of 1.3 lead me to believe that this was a evolutionary
not revolutionary change. If I am mistaken, then I would have to agree
with Toby Butzon, that the next version is should be a 2.0 version
since its use with existing code would be precluded.
>> Lets be realistic about this issue. A vote is not needed here,
>> adding a trace level would not change any existing functionality.
>> Those that do not want it do not have to use it. I can only see two
>> valid reasons for not including TRACE as a natively supported level.
>>
>> 1) No resources available to implement, test or maintain the change.
>> 2) Change is incompatible with or contrary to current functionality
>
> There is also:
>
> 3) Change works contrary to future functionality.
If an additional level is contrary to future functionality, then the
existing levels would also be contrary, which brings me back to the
feeling that this next version is a 2.0 release. If this is the case,
what will be the future for version .12.n?
>> I would think that any other reason for rejection would leaning
>> toward the "personal". Since the addition of a TRACE level could
>> hardly be seen as being incompatible, would a contribution of the
>> patch to add the native support for the TRACE level be accepted from
>> an "non-comitter"?
>
> The implementation question is hardly an issue here.
>
> Some users are asking for the TRACE level. My response was: please
> wait for the domain functionality to crystallize and then, if you
> remain unconvinced, let us have this discussion again.
Now I am confused, if you would be willing to entertain discussion at a
later time, then how would a new level be contrary to the next release
> I think it is very unfair to qualify our reaction on this matter as
> condescending or trivializing [the requested change]. If my memory
> serves me correctly, this is the first flame war on this mailing list,
> ever. I am actually not sure what to make of it.
First, I would hardly consider what I have been reading, for the past
month, as "flame war". I may be presumptuous here, but I think it was
my query when I first joined the list that might have started this
latest round, but there have been several threads. It was stated that
a valid case had not yet been made for a new level. I feel that most
of what I have seen here has been a very civil attempt to make that
case. There seems to be some difference of opinion on where the new
"development level" fits (above or below DEBUG), but I think the case
for another development level has been clearly made.
I never said your (or anyones) reaction was condescending, I meant no
personal disrespect to anyone. I think the term is used was
"trivialize" which means "to assign little significance or value". I
kept seeing how "domains" were going to solve the problem, but I don't
think they will be feasible for many of us.
I for one have a lot of code to maintain based upon the levels
concepts. A wholesale conversion to use domains would not be possible.
Your comment here about a new level being contrary to future
functionality (domains?) actually scares me a little. So I personally
would like a little more clarification. Will the levels concept be
supported in the next release?
>
>
> --
> Ceki Gülcü
>
> For log4j documentation consider "The complete log4j manual"
> ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
> import org.apache.Facetime;
> ApacheCon US 2003, 18-21 November http://apachecon.com/
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Jim Moore <lo...@mooresoft.net>.
Ceki's comments do sound like that, but giving them a more charitable
reading I suspect that he simply wants to make sure that everything's clear
when he does a full explanation, and so is taking time to do a proper "write
up." ApacheCon is merely the deadline for getting everything ready. If
that's the case, then personally I'd be "publishing" my drafts to this list
well before the conference to make sure all the holes are filled as this
group is better able to deal with incomplete information than the general
user community. But I'm kind of paranoid when it comes to making a major
announcement like that when it hasn't been scrutinized by others first...
----- Original Message -----
From: "Wolf Siberski" <si...@learninglab.de>
To: "'Log4J Developers List'" <lo...@jakarta.apache.org>
Sent: Monday, November 03, 2003 5:11 AM
Subject: RE: Rationale for TRACE-level/priority.
[snip]
ps: I must admit that I find it a bit strange that publication of the design
and source code for a new concept is delayed for the sake of increasing
the attraction of a conference. But maybe this is a too idealistic view
of open source development.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Mon, 3 Nov 2003, Wolf Siberski wrote:
| You would write:
|
| public class Sample {
| private static Logger tracer = Logger.getLogger("my.log.hierarchy",
| "my.levels.trace");
| private static Logger errlog = ...;
| ...
| if (tracer.isEnabled()) tracer.log("User [id:"+user.getId()+"] added
| to update queue.");
| }
Then I'd have to make 6 loggers, right? fatalLog, errorLog .. traceLog.
I could do that now too. E.g. simply add ".TRACE" behind the
category-name. Or in front - or something else. I do get the point with
domains (why it'd be cool), it does seem nice (and I've often had the
desire to log a statement to two different places in the hierarchy), but I
think levels are quite different.
| If you like the current logging style more, just write a small
| wrapper class:
I could do that now too, right?
I'd prefer not to. I'd prefer to use the existing functionality of the
system. And I don't feel that updating my entire code base is acceptable.
| I didn't do any performance measurements, but I'm pretty sure
| that the additional call of a final method is negligible
| (probably zero if the compiler does decent optimization).
Since this is dynamic, either the entire forest of Loggers will have to be
updated on a log-reconfigure (which would imply synching on every
access, or maybe a volatile could do?), or the Logger itself will have to
check multiple places (a List of domains it's attached to?). It alreay
have to check multiple places, but it "quick-returns" if it is directly
turned off, apparently.
| > b) Levels define an implicit view of the -importance- of a
| > log-statement -
| > and not "where it comes from", or who should view it, as such. It's a
| > descriptive -importance level-. Domains wont supersede this.
|
| This depends on how abstract domains are designed. From a conceptual
| viewpoint, you have several dimensions of categories (logger names,
| levels, etc.) which don't need to be implemented by different means.
| Based on this abstraction everyone can choose (or create) his
| personal logging dimensions, of which 'where it comes from' and
| 'importance level' are just two examples.
Oh, well, the flexibility! Like .NET: code in every single programming
language on the earth. It really makes the maintenance of the code a
breeze, doesn't it?
I'd like to have a linear list of importance levels to which I could
decide to log "with" (using one single Logger instance!!), I just feel
strongly that one level is missing.
View the levels as simply a "tag" (among a highly fixed set of such tags)
that denotes the level of importance that a log statement should have. It
does not represent "a domain" as such, it's a piece of metadata about the
statement stating the importance.
Maybe I'm simply on mushrooms or something, could be yesterdays pizza. But
I don't think domains will make the levels outdated and obsolete -
however, I can see that domains will be a cool way to "route" the log
statements.
|
| > c) Trace is something else!
| In the view described above it's just one more category in one dimension.
Oh, well.
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
RE: Rationale for TRACE-level/priority.
Posted by Wolf Siberski <si...@learninglab.de>.
Let me start with a small disclaimer: I don't know anything about
Ceki's (and possibly other log4j developers) concept of domains
except what he wrote about it in this newsgroup.
However, I can imagine the following:
Currently, we have one configurable dimension of categories
for log entries (the logger name hierarchy) and one hard-coded
dimension (the level 'hierarchy'). A much more flexible
concept would be to allow the creation of loggers which are
assigned to arbitrary many, configurable categories.
Then everyone could introduce as many levels as necessary,
just as it is possible now with logger names.
> From: Endre Stølsvik [mailto:Endre@Stolsvik.com]
[snip]
> a) Performance impacts, as trace is an extremely verbose level.
This approach should not impact performance at all. Maybe some
more static variables are necessary. I would imagine the following
usage. Instead of writing:
public class Sample {
private static Logger log = Logger.getLogger("my.log.hierarchy");
...
if (log.isTraceEnabled()) log.trace("User [id:"+user.getId()+"] added
to update queue.");
}
You would write:
public class Sample {
private static Logger tracer = Logger.getLogger("my.log.hierarchy",
"my.levels.trace");
private static Logger errlog = ...;
...
if (tracer.isEnabled()) tracer.log("User [id:"+user.getId()+"] added
to update queue.");
}
Maybe you like to introduce another dimension, e.g. the
kind of access (read access vs. write access). That would allow
you to ignore all read access log entries should any problems with
data corruption occur:
public class Sample {
private static Logger writeTracer = Logger.getLogger("my.log.hierarchy",
"my.levels.trace", "my.access.write");
private static Logger errlog = ...;
...
if (writeTracer.isEnabled()) writeTracer.log("User [id:"+user.getId()+"]
added to update queue.");
}
If you like the current logging style more, just write a small
wrapper class:
public class MyLogger {
private Logger errLog;
private Logger traceLog;
...
public MyLogger(String name) {
errlog = Logger.getLogger(name, "my.levels.error");
...
}
public final isTraceEnabled() {
return traceLog.isEnabled();
}
public final trace(String s) {
traceLog.log(s);
}
}
I didn't do any performance measurements, but I'm pretty sure
that the additional call of a final method is negligible
(probably zero if the compiler does decent optimization).
Btw., you could do something similar even with the current
version to hide a self-defined Level subclass.
> b) Levels define an implicit view of the -importance- of a
> log-statement -
> and not "where it comes from", or who should view it, as such. It's a
> descriptive -importance level-. Domains wont supersede this.
This depends on how abstract domains are designed. From a conceptual
viewpoint, you have several dimensions of categories (logger names,
levels, etc.) which don't need to be implemented by different means.
Based on this abstraction everyone can choose (or create) his
personal logging dimensions, of which 'where it comes from' and
'importance level' are just two examples.
> c) Trace is something else!
In the view described above it's just one more category in one dimension.
As I said, I have no idea if this is what Ceki has in mind,
these are just conjectures.
--Wolf
ps: I must admit that I find it a bit strange that publication of the design
and source code for a new concept is delayed for the sake of increasing
the attraction of a conference. But maybe this is a too idealistic view
of open source development.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Sun, 2 Nov 2003, Ceki Gülcü wrote:
|
| Domains result from an *internal* refactoring of loggers. In 1.2.8 a logger
| is:
|
| 1) an object where appenders can be attached to, and
| 2) an object which can decide whether a log statement is enabled or not
|
| In the next version of log4j, a logger can be viewed as a shell around one
| or more domains, where domains are:
|
| 1) an object where appenders can be attached to, and
| 2) an object which can decide whether a log statement is enabled or not
|
| A logger just glues multiple domains together. A logger has fixed rules
| defining the interaction of the domains it contains.
|
| A hierarchy is a space where multiple domains live in a hierarchical setup.
| It can be viewed as a forrest where multiple trees (i.e. domains linked in
| a tree like structure) live.
|
| I hope this sheds some light on this topic. Much better documentation will
| become available in the near future.
Pretty much what I'd expect, but how does a Logger decide if it should log
or not? This sounds like a lot of overhead (it has to check its entire
list of attached domains? Or is there a way to "quick-return" if the
statement shouldn't log?).
And definately a 2.0 thing, this is no small refactor.
|
| Coming back to the TRACE level, I think that domains may offer a better
| alternative. The ongoing discussion has raised some very interesting
| questions to which I do not have definitive answers.
You haven't answered my post on this.
a) Performance impacts, as trace is an extremely verbose level.
b) Levels define an implicit view of the -importance- of a log-statement -
and not "where it comes from", or who should view it, as such. It's a
descriptive -importance level-. Domains wont supersede this.
c) Trace is something else!
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Toby Butzon <to...@ilc.com>.
Ceki Gülcü wrote:
> I hope this sheds some light on this topic.
This may have given us a keyhole to look through and see a tiny portion
of what "domains" will be, but it doesn't really help us understand
anything about it.
> The ongoing discussion has raised some very interesting
> questions to which I do not have definitive answers.
And that's the reason any sort of development should start with
discussion, not implementation.
I don't mean to be jumping you here; after all, I'm fairly new to this
list. However, it doesn't make sense to me that you're working on
implementing a very significant change here, and the first thing the
-dev list hears about is (almost) PR-type hype. Ideally, we would have
already talked about this new feature, discussed its ups and downs,
talked about what we should watch out for during and after
implementation, and so on.
Furthermore, I agree that if/when this is implemented, it should be the
next major version, and in no way should that stop us from putting TRACE
in the next minor version. The discussion of domains, IMHO, is
completely irrelevant to the TRACE issue.
--
Toby Butzon <to...@ilc.com>
ILC R&D Co-op / Georgia Tech CS / KKPsi Iota Sp03
678.904.2413 work / 678.362.6483 mobile
Fifteen Piedmont Center, Suite 700 / Atlanta, GA 30305
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:31 PM 11/1/2003 -0600, Jacob Kjome wrote:
>>>How was it established that domains will not replace levels?
>>
>>Maybe that was just an assumption, on my part, but I did ask in a
>>previous message if domains were going to replace levels, Also the
>>release number, of 1.3 lead me to believe that this was a evolutionary
>>not revolutionary change. If I am mistaken, then I would have to agree
>>with Toby Butzon, that the next version is should be a 2.0 version since
>>its use with existing code would be precluded.
>
>I think I tend to agree with the next version of Log4j being called 2.0
>rather than 1.3 since so much new functionality will be there. However, I
>have to disagree with your assumption that use of 1.3 or 2.0 with existing
>code would be precluded. No one has ever mentioned throwing out backward
>compatibility. As far as I know, Levels will not be going away, even if
>alternatives are being developed.
Domains will be encapsulated by Loggers so that the net version of log4j
(1.3 or 2.0) will be *totally* compatible with existing code. In order
words, you can count on 100% backward compatibility.
[large snip]
>I haven't discussed this personally with Ceki, but I until I hear
>differently, I think the simple answer is "yes", levels *will* be
>supported in the next version of Log4j, possibly deprecated, though. The
>idea being eventual migration to logging domains, especially with newer
>codebases that don't yet have any dependency on levels. Consequently, the
>avoidance of adding new levels will probably encourage migration to
>logging domains.
Jake, thank you very much for taking the time to give a lengthy answer to
Dennis. The prevailing sentiment in relation to domains seems to be
confusion. This lack of clarity can be attributed entirely to me because I
keep talking about domains without giving any precise details. Here are
some details:
Domains result from an *internal* refactoring of loggers. In 1.2.8 a logger
is:
1) an object where appenders can be attached to, and
2) an object which can decide whether a log statement is enabled or not
In the next version of log4j, a logger can be viewed as a shell around one
or more domains, where domains are:
1) an object where appenders can be attached to, and
2) an object which can decide whether a log statement is enabled or not
A logger just glues multiple domains together. A logger has fixed rules
defining the interaction of the domains it contains.
A hierarchy is a space where multiple domains live in a hierarchical setup.
It can be viewed as a forrest where multiple trees (i.e. domains linked in
a tree like structure) live.
I hope this sheds some light on this topic. Much better documentation will
become available in the near future.
Coming back to the TRACE level, I think that domains may offer a better
alternative. The ongoing discussion has raised some very interesting
questions to which I do not have definitive answers.
>Jake
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
import org.apache.Facetime;
ApacheCon US 2003, 18-21 November http://apachecon.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Dennis Cook <de...@cook-mail.net>.
>
> And now for something a little different:
>
> A little argument for "Trace" being lower (more verbose) than debug:
> ...
If another development level were added, I don't think it would matter
much if it added above or below DEBUG. At least I would not care,
my only desire was to have more than one development level.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Endre Stølsvik <En...@Stolsvik.com>.
| I haven't discussed this personally with Ceki, but I until I hear
| differently, I think the simple answer is "yes", levels *will* be supported
| in the next version of Log4j, possibly deprecated, though. The idea being
| eventual migration to logging domains, especially with newer codebases that
| don't yet have any dependency on levels. Consequently, the avoidance of
| adding new levels will probably encourage migration to logging domains.
There is an existing LARGE userbase that uses levels, which -won't- switch
to domains on their existing projects. Maybe new projects will use
domains, but not the existing projects. But maybe (as for our system) the
existing projects are -that- large that they won't "ever" be finished.
They will, though, forever still be maintained, and evolved and have lots
of new code added, and lots of old code refactored etc. THIS use case
would still like to have trace - even though domains -possibly- would be
better (although I feel that it's a COMPLETLY different idea - but good).
"Encourage migration". Well, isn't that a bit "haevy-handed"? I haven't
ever asked for domains. I don't think, based on what I've heard so far,
that I'd be satisfied with domains (As I've already stated, I use the
categories in a more "reflected" manner than simply the classname, hence I
already have a notion of the "domain" of the log lines). Thus, this is a
forced migration into something that I haven't asked for, and the existing
functionalty won't get updated or developed to what I (and others, right?)
am asking for.
Based on what I've understood of domains so far, I also put a question
mark at the performance of domains, vs.:
if (log.isTraceEnabled()) log.trace("User [id:"+user.getId()+"] added to update queue.");
This is probably the absolutely fastest thing that can be done (I believe)
- a simple boolean no-args method, that (hopefully!) is made to be a
simple boolean check and return if disabled. Making your own trace level,
means that the if would have to pass an argument to the
isLevelEnabled(level), and that method again would have to do a further
lookup. The domains-thing so far seems like a "string-based" lookup, which
to me sounds even worse.
The deal here is that since the trace-level should return the absolutely
most amount of imformation (an argument for this below!), this exact
method should have the absolutely least amount of overhead to the "is it
on" check - this, of course, to be able to leave those statements behind
when you're finished with the code - being ensured that it doesn't make a
(significatnt) overhead to the all around opearation of the code.
Then again, I might be totally mistaken ..
Or maybe we all should migrate to preprocess our code?!
And now for something a little different:
A little argument for "Trace" being lower (more verbose) than debug:
"tracing" an application is usually referring to "step-locking"
through code, that is, seeing every single change to every single register
in the processor, for every operation. For unixers, "strace" and "ltrace"
are the tools by which -all- system calls / library calls are "traced".
The "trace" word hence, in my opinion, have an established meaning as
something -extremely- verbose: it -traces- the applications every single
step.
Debug information, on the other hand, is more for being able to debug
the application as a whole (and this is, of course, a very overlapping
area!). You'd like to see when the application asks the dbpool for an
connection (maybe? - the 40 steps required within the dbpool to fetch this
connection are at least definately trace-level outputs), you'd like to see
that the user made some "semantic action", e.g. "loaded customer data".
This is more "contextual" information, e.g. "the user such and so mande
the this and that action", and, implicitly, if you'd turn on trace, you'd
see -which- small, single-steps that have been done to accomplish this
action.
I don't know if this was extremely elucidating, but hey..!
Here's some dictionary lookups:
Onlook.com:
http://onelook.com/?w=trace&ls=a
Dictionary.com:
http://dictionary.reference.com/search?q=trace
Tiscali's computer dictionary:
http://www.tiscali.co.uk/reference/dictionaries/computers/data/m0034421.html
CSGNetwork.Com:
http://www.csgnetwork.com/glossaryt.html#trace
Some quotes:
"A method of checking that a computer program is functioning correctly by
causing the changing values of all the variables involved to be displayed
while the program is running."
"To follow the course or trail of: trace a wounded deer; tracing missing
persons."
"To determine the "flow" of a program, often used as a synonym to debug".
"To locate or discover by searching or researching evidence: trace the
cause of a disease."
"A mark left by anything passing; a track; a path; a course; a footprint;
a vestige; as, the trace of a carriage or sled; the trace of a deer; a
sinuous trace."
"A mark, impression, or visible appearance of anything left when the thing
itself no longer exists; remains; token; vestige"
"To follow by some mark that has been left by a person or thing which has
preceded; to follow by footsteps, tracks, or tokens."
"a clue that something has been present; "there wasn't a trace of evidence
for the claim" "
"A line drawn by a recording instrument, such as a cardiograph."
Seems to me like "log4j" maybe should have it's name changed to the more
descriptive "trace4j", or what?! ;)
--
Mvh,
Endre Stølsvik M[+47 93054050] F[+47 51625182]
Developer @ CoreTrek AS - http://www.coretrek.com/
CoreTrek corporate portal / EIP - http://www.corelets.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org
Re: Rationale for TRACE-level/priority.
Posted by Jacob Kjome <ho...@visi.com>.
At 08:53 AM 11/1/2003 -0800, you wrote:
>On Friday, October 31, 2003, at 11:10 AM, Ceki Gülcü wrote:
>
>>At 08:29 AM 10/31/2003 -0800, Dennis Cook wrote:
>>
>>>>2) make a personal issue out of this topic
>>>
>>>Since all use of any level is subjective, a refusal to add a TRACE
>>>level, that seems to be a highly request feature, can only be seen as a
>>>"personal" issue already. It has already been established that domains
>>>will not replace levels, so for those that may not have the option of
>>>moving to the use of domains, a TRACE level is still an unmet need.
>>
>>How was it established that domains will not replace levels?
>
>Maybe that was just an assumption, on my part, but I did ask in a previous
>message if domains were going to replace levels, Also the release number,
>of 1.3 lead me to believe that this was a evolutionary not revolutionary
>change. If I am mistaken, then I would have to agree with Toby Butzon,
>that the next version is should be a 2.0 version since its use with
>existing code would be precluded.
I think I tend to agree with the next version of Log4j being called 2.0
rather than 1.3 since so much new functionality will be there. However, I
have to disagree with your assumption that use of 1.3 or 2.0 with existing
code would be precluded. No one has ever mentioned throwing out backward
compatibility. As far as I know, Levels will not be going away, even if
alternatives are being developed.
>>>Lets be realistic about this issue. A vote is not needed here, adding a
>>>trace level would not change any existing functionality.
>>>Those that do not want it do not have to use it. I can only see two
>>>valid reasons for not including TRACE as a natively supported level.
>>>
>>>1) No resources available to implement, test or maintain the change.
>>>2) Change is incompatible with or contrary to current functionality
>>
>>There is also:
>>
>>3) Change works contrary to future functionality.
>
>If an additional level is contrary to future functionality, then the
>existing levels would also be contrary, which brings me back to the
>feeling that this next version is a 2.0 release. If this is the case,
>what will be the future for version .12.n?
I think you misunderstand. It seems to me that logging domains will
provide all the functionality and more that levels provided in the
past. So, in that sense, yes, "existing levels would be contrary" to
future functionality. But this is an issue of backward
compatibility. Log4j will keep the old levels around to keep from breaking
peoples existing code. Existing code has no dependence on a Log4j TRACE
level. So, while existing levels are contrary, they are necessary. The
TRACE level is currently not necessary. See the difference?
Furthermore, assuming that domains will actually cover all the
functionality that Levels did, but in a more flexible and extensible way,
why bloat Log4j with continued development the old, less sophisticated,
less flexible, paradigm of levels?
>>>I would think that any other reason for rejection would leaning toward
>>>the "personal". Since the addition of a TRACE level could hardly be
>>>seen as being incompatible, would a contribution of the patch to add
>>>the native support for the TRACE level be accepted from an "non-comitter"?
>>
>>The implementation question is hardly an issue here.
>>
>>Some users are asking for the TRACE level. My response was: please
>>wait for the domain functionality to crystallize and then, if you
>>remain unconvinced, let us have this discussion again.
>
>Now I am confused, if you would be willing to entertain discussion at a
>later time, then how would a new level be contrary to the next release
If it is determined by you, the user, (after actually experiencing domains)
that domains aren't actually all of what they are cracked up to be and you
make a good case that levels should continue to be the future of Log4j
development efforts, then levels would no longer be contrary to the future;
they would be the future. Current thinking in the Log4j developer camp is
that domains will supercede levels, so additions to levels have been put on
hold pending future findings.
>>I think it is very unfair to qualify our reaction on this matter as
>>condescending or trivializing [the requested change]. If my memory
>>serves me correctly, this is the first flame war on this mailing list,
>>ever. I am actually not sure what to make of it.
>
>
>First, I would hardly consider what I have been reading, for the past
>month, as "flame war".
Maybe not a "flame war", but certainly an emotional battle of wills. It
hasn't degenerated into stuff like "well, you suck", but it has managed to
stray off the normally calm, cool, and collected discussions that we're
used to.
> I may be presumptuous here, but I think it was my query when I first
> joined the list that might have started this latest round, but there have
> been several threads. It was stated that a valid case had not yet been
> made for a new level. I feel that most of what I have seen here has been
> a very civil attempt to make that case. There seems to be some
> difference of opinion on where the new "development level" fits (above or
> below DEBUG), but I think the case for another development level has been
> clearly made.
What is currently holding up a TRACE level from being added to Log4j proper
are the following (IMO, of course)...
1. Many feel that the current levels are quite adequate for the job. Just
enough and not more.
2. Advocates of TRACE can't quite agree what it is to be used for (as you
alluded to above).
3. Many use DEBUG for what you insist on using TRACE for and are fine with
that.
4. logging domains look to be the future and, hence, the focus of Log4j
development. As such, attention to older paradigms fall by the wayside
(other than keeping the status quo for backward compatibility).
5. Given the above (especially #4), adding another level to a future
release of Log4j could only be considered bloat.
>I never said your (or anyones) reaction was condescending, I meant no
>personal disrespect to anyone. I think the term is used was "trivialize"
>which means "to assign little significance or value". I kept seeing how
>"domains" were going to solve the problem, but I don't think they will be
>feasible for many of us.
I never picked up on any disrespect from you, but you did try to make your
point by raising your voice rather than raising the level of
discussion. I'll leave it at that.
>I for one have a lot of code to maintain based upon the levels
>concepts. A wholesale conversion to use domains would not be
>possible. Your comment here about a new level being contrary to future
>functionality (domains?) actually scares me a little. So I personally
>would like a little more clarification. Will the levels concept be
>supported in the next release?
I haven't discussed this personally with Ceki, but I until I hear
differently, I think the simple answer is "yes", levels *will* be supported
in the next version of Log4j, possibly deprecated, though. The idea being
eventual migration to logging domains, especially with newer codebases that
don't yet have any dependency on levels. Consequently, the avoidance of
adding new levels will probably encourage migration to logging domains.
Jake
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-dev-help@jakarta.apache.org