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 "Geir Magnusson Jr." <ge...@optonline.net> on 2004/03/10 22:59:29 UTC
Re: TRACE!!! (Was: Re: Log4j Domains - Volunteer)
On Feb 23, 2004, at 3:34 PM, Mark Womack wrote:
> Geir,
>
> Geez, I've been waiting for you to stand up and ask about the vote
> that was
> promised at ApacheCon.
LOL :)
>
> All we need is someone to propose the changes to they can be reviewed
> (not
> torn apart as Endre says) and voted on. The change should be backward
> compatible.
So, what was the verdict?
geir
>
> -Mark
>
> -----Original Message-----
> From: Geir Magnusson Jr. [mailto:geirm@optonline.net]
> Sent: Monday, February 23, 2004 11:31 AM
> To: Log4J Developers List
> Subject: Re: TRACE!!! (Was: Re: Log4j Domains - Volunteer)
>
>
>
> On Feb 23, 2004, at 9:32 AM, Endre Stølsvik wrote:
>
>> On Thu, 19 Feb 2004, Paul Smith wrote:
>>
>> | On Thu, 2004-02-19 at 05:00, Thiyagu wrote:
>> | > Hi,
>> | > I 'm interested in participating in the Log4j developement
>> | > activities. Please let me know if I can help on the task "Log4j
>> | > Domains".
>> |
>> | Hi,
>> |
>> | Thank you for your offer. Ceki is currently working on Domains at
>> the
>> | moment, but unfortunately he is currently out of action while he
>> | recovers from surgery. I will leave it to Ceki to discuss with you
>> any
>> | options in participating, but don't feel bad if any response takes a
>> | while, I think he might be out of action for another week or so.
>>
>> How's TRACE level logging coming along, BY THE WAY??
>>
>> (I said I'd chill a couple of months before starting to whine
>> again..)
>>
>> Not only that "all" projects I'm having a peek at, including most at
>> Apache, use Trace, but -I- would like it a lot...!!
>
> :D
>
> +1
>
> geir
>
>>
>> Endre.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>>
>>
> --
> Geir Magnusson Jr 203-247-1713(m)
> geir@4quarters.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Sat, 27 Mar 2004, Ceki Gülcü wrote:
|
| No vetos. So the vote passed.
Finally, log4j will become complete.. ;-p
When can we expect a version with the changes added? (I did submit a patch
containing everything (hopefully) that is needed.. Oh, btw, come to think
about it, I haven't done anything with those GUI thingys - but the log4j
proper worked, at least..)
Endre.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Ceki Gülcü <ce...@qos.ch>.
No vetos. So the vote passed.
At 03:12 AM 3/27/2004 +0100, you wrote:
>On Mon, 15 Mar 2004, Ceki Gülcü wrote:
>
>|
>| Let's wait until Wednesday to close the ballot.
>|
>
>So, what happened?!
>
>;-)
>
>Regards,
>Endre, who is looking forward to gigabytes of tracelines in the logfiles!
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Mon, 15 Mar 2004, Ceki Gülcü wrote:
|
| Let's wait until Wednesday to close the ballot.
|
So, what happened?!
;-)
Regards,
Endre, who is looking forward to gigabytes of tracelines in the logfiles!
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Ceki Gülcü <ce...@qos.ch>.
At 08:35 PM 3/13/2004 +0100, Joern Huxhorn wrote:
>I don't really see the need for a 2/3 majority for a minor enhancement
>like this. If only 25% of the userbase need a feature it will be
>reimplemented over and over again by those 25% which isn't very
>productive. I understand that the API shouldn't be bloated unnecessary but
>trace-support doesn't add a lot of bloat at all and is significant for
>quite some people.
Our current rules require lazy consensus meaning that a single veto,
i.e. a -1 vote, can block the proposed change. Those are the existing
and prevalent rules at Apache. We should not simply dismiss the rules out
of convenience.
Now, given that most people voted in favor of the change and no one except
me against the change, I hereby alter my vote to 0 in order to
accommodate both the existing rules and the wishes of the majority.
Thus we have, three +1 votes (counting Paul's vote as +1) and three 0
votes (counting Jim's vote). Note that Mark has not voted yet.
Let's wait until Wednesday to close the ballot.
Cheerio.
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Toby Butzon <to...@ilc.com>.
+1
Most of the points I might've mentioned have already been made. I would
like to comment on a few things, though:
1. We don't need to change voting procedures. If the veto thing
seems wrong after multiple votes, then we can think about it
on logging-general.
2. The options Ceki listed omit the +0/-0 difference. If you don't
agree personally, but don't have a serious reason to stop it, vote
-0 instead of -1. (See bylaws.)
3. The issue isn't about domains or other levels. Even when domains
are in the stable release, many may choose to stick with simply
using levels. Would the proposed level be useful to users of
log4j? [It seems that it would be to a significant percentage.]
Will it hurt anything? [One additional level with good cause,
which I believe its proponents have, is NOT code bloat. I haven't
seen any argument for it causing harm.]
--
Toby Butzon
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Elias Ross <er...@m-qube.com>.
+1
Personally, I think the TRACE feature is dubious at best. If it was me
writing for myself, I'd say -1, but if it makes the user base happy and
if log4j is truly user-driven, then let's do it. It's not going to do
much harm for the rest of us who don't need it. (But I would have to
draw the line at adding FINE, FINER, FINEST as well.)
For people who like having a TRACE level, I'd like to hear how it has
been helpful to them. I believe it's one of those features that sounds
good when you use if, but is hardly useful in real practice.
Personally, if you structure your classes into logical packages and put
in useful debug information--NOT spurious junk--then with careful level
filtering you'll get the right amount of useful data.
Here are the common problems I see with people using logging:
1. Gigantic classes or packages, leading to not enough categories
2. Log lots of data about things we don't care about. For example,
instead of showing data points X Y Z, we see A B C D E F ... X Y Z.
3. Data isn't checked properly. If the data looks wrong, throw an
exception! Validate all data if it is easy to do so. Make the
exception explain what data is wrong, throw exceptions with messages.
4. Log statements with no reason for existence.
5. Log statements within large loops that write out 100+ times.
So, for people who can't use logging properly, TRACE isn't going to
improve their situation: Likely people will feel free to *add more*
logging, which is going to decrease the S/N ratio.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by WJCarpenter <bi...@carpenter.ORG>.
+1
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Jacob Kjome <ho...@visi.com>.
+1
However, isn't there a potential problem with the fact that many servers
include logj4 in the classpath by default? I just had some experience with
Weblogic's ridiculous classloading behavior (of course, the real issue was
with commons-logging, but I'll take a short rest on bashing that, ummm....,
"product" today) where I was forced to put Log4j, commons-logging, and a
bunch of other jars in the server's classpath and remove them from
WEB-INF/lib of the webapp, otherwise Struts would die a nasty death. The
point is, if one starts using logger.trace("blah blah blah") in their
applications and tries to deploy on Weblogic where they can't include log4j
in WEB-INF/lib and have no control over what version the server includes,
their app won't work if the server includes Log4j pre 1.3.
On the other hand, one could make the same argument for any other new
features in 1.3 such as domains, the new repository selector
implementations, using Joran for configuration, etc. As long as the
community is willing to live with the fact that certain server
implementations (read "Weblogic") provide crappy classloading behavior and
will have to be worked around in order to take advantage of any new logj4
features, I'm all for the change if the community wants it as it won't hurt
anything any more than any other new feature would.
Jake
At 04:30 PM 3/12/2004 +0100, you wrote:
>Hi All,
>
>The issue has been discussed several times in the log4j mailing lists
>and great many users have asked for it. Consequently, here is a formal
>vote to include the TRACE level.
>
>[ ] +1, Yes, the TRACE would be a useful addition
>[ ] 0, I don't care
>[ ] -1, No, TRACE should not be included
>
>I would like to vote -1 due to the following arguments:
>
>- Many people use INFO and DEBUG for development, eliminating the need
> for TRACE. One uses DEBUG to output chatty information and INFO to
> output an overview the application's progress.
>
>- The next version of log4j will introduce the concept of domains
> allowing developers to log by multiple criteria, thus creating a much
> more powerful way of categorizing (i.e. classifying) logging
> statements, thus dispensing with the need to use various new levels
> (e.g. the trace level) to express logging/filtering criteria. With the
> introduction of domains the trace level will look like what it really
> is, a common but nonetheless a lame hack.
>
>- It is possible to wrap the Logger class and extend the Level class to
> include support for the trace level.
>
>- Moreover, The generic log() method in the Logger class takes in a
> Level as its first parameter. This allows the developer to log at
> any level, including the trace level. For example:
>
> Logger logger = Logger.getLogger("some.logger.name");
> logger.log(XLevel.TRACE, "some message");
>
> where [XLevel] class extends the Level class by adding the trace
> level. There is a section about in the FAQ as well:
> http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceLevel
>
> Although typing in this method call is slightly longer than typing the
> usual printing methods such as logger.debug("message") or
> logger.info("message"), modern IDEs can easily automate the process.
>
>
>Given that code changes require lazy consensus, this veto kills the
>vote right in the bud. Note this is the usual procedure for reaching a
>decision at Apache. At the same time, it does not seem right to me
>that a single individual should be able to overrule everyone else,
>especially if that person happens to be me.
>
>Maybe we should change the Logging Services bylaws to demand a 2/3
>majority or just a simple majority instead of lazy consensus for code
>changes. What do you guys think?
>
>
>--
>Ceki Gülcü
> For log4j documentation consider "The complete log4j manual"
> ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Joern Huxhorn <jo...@gmx.de>.
+1
Because
- I don't think this change will hurt a lot of people. Those that are
hurt just need to remove their previous custom-made trace. This would
most likely only require a global search/replace or some comparable
refactoring.
- common.logging has it. People using this API miss it.
- .net has it
- without it, a (proper) trace-call would look like this:
if(log.isEnabledFor(XLevel.TRACE)) log.log(XLevel.TRACE, <probably very
expensive string creation>)
instead of
if(log.isTraceEnabled()) log.trace(<probably very expensive string
creation>)
which is less obscuring in the code. After all we are talking about the
trace-level, the finest grained default level, which means that there
will be lots of lines like the above in the source! This is one of the
main reason why it should be included. Readable code is important.
- I can't wait until Chainsaw and other supporting applications support
the trace-level "natively".
- the existance of
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceLevel
tells me that it should be included since it's obviously requested quite
a lot.
- I don't want to restart any religious discussions but:
- INFO is for informational Messages like "User Foo logged in."
Those would appear in ordinary log-files of applications if they are
turned verbose in production.
- DEBUG is for standard development like "Received message of
type <TYPE>" just to see what's going on generally.
- TRACE would probably do a hex-dump of the received message. I'm
talking about lots of output here that is slowing down the execution
significantly. This would be used to see what's going on in depth.
Even if this is different from other peoples view, wouldn't it be
best to stop this discussion/holy war/Förmchenkrieg once and for all by
just including trace for "people like me"?
I don't really see the need for a 2/3 majority for a minor enhancement
like this. If only 25% of the userbase need a feature it will be
reimplemented over and over again by those 25% which isn't very
productive. I understand that the API shouldn't be bloated unnecessary
but trace-support doesn't add a lot of bloat at all and is significant
for quite some people.
Don't get me wrong but if I had to choose right now between trace and
domains I'd choose trace since I really need it while the domains just
sound nice and I don't see any immediate use (for me).
How long will this vote run? Is it worth a "Trace now!"-Ribbon-Campaign? ;)
Thank you for choosing the democratic way!
Joern.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
RE: [VOTE] Adding the TRACE level
Posted by Wolf Siberski <si...@learninglab.de>.
+1
IMHO adding the TRACE level imposes no burden on the current or
future log4j development. It's just a trivial extension which
doesn't add any new complexity or blocks future changes.
If users want a feature which log4j can give them nearly
for free, why not do it? Even if it may not be the optimal
approach to logging.
--Wolf
> -----Original Message-----
> From: Ceki Gülcü [mailto:ceki@qos.ch]
> Sent: Friday, March 12, 2004 5:30 PM
> To: Log4J Developers List
> Subject: [VOTE] Adding the TRACE level
>
>
>
>
> Hi All,
>
> The issue has been discussed several times in the log4j mailing lists
> and great many users have asked for it. Consequently, here is a formal
> vote to include the TRACE level.
>
> [ ] +1, Yes, the TRACE would be a useful addition
> [ ] 0, I don't care
> [ ] -1, No, TRACE should not be included
>
> I would like to vote -1 due to the following arguments:
>
> - Many people use INFO and DEBUG for development, eliminating the need
> for TRACE. One uses DEBUG to output chatty information and INFO to
> output an overview the application's progress.
>
> - The next version of log4j will introduce the concept of domains
> allowing developers to log by multiple criteria, thus
> creating a much
> more powerful way of categorizing (i.e. classifying) logging
> statements, thus dispensing with the need to use various new levels
> (e.g. the trace level) to express logging/filtering
> criteria. With the
> introduction of domains the trace level will look like
> what it really
> is, a common but nonetheless a lame hack.
>
> - It is possible to wrap the Logger class and extend the
> Level class to
> include support for the trace level.
>
> - Moreover, The generic log() method in the Logger class takes in a
> Level as its first parameter. This allows the developer to log at
> any level, including the trace level. For example:
>
> Logger logger = Logger.getLogger("some.logger.name");
> logger.log(XLevel.TRACE, "some message");
>
> where [XLevel] class extends the Level class by adding the trace
> level. There is a section about in the FAQ as well:
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages
/TraceLevel
Although typing in this method call is slightly longer than typing the
usual printing methods such as logger.debug("message") or
logger.info("message"), modern IDEs can easily automate the process.
Given that code changes require lazy consensus, this veto kills the
vote right in the bud. Note this is the usual procedure for reaching a
decision at Apache. At the same time, it does not seem right to me
that a single individual should be able to overrule everyone else,
especially if that person happens to be me.
Maybe we should change the Logging Services bylaws to demand a 2/3
majority or just a simple majority instead of lazy consensus for code
changes. What do you guys think?
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [VOTE] Adding the TRACE level
Posted by Jim Moore <lo...@mooresoft.net>.
+0
I've done the custom TRACE level as an argument to Logger.log. (I was the
one that wrote the Wiki page...) As noted, modern IDEs automate the task.
However, over time my team and I stopped using TRACE because in use we
didn't really see a need for it. We thought we did, but we were wrong.
Doesn't mean that other people don't need that, though.
While domains are definitely cool, the fact is that people think in terms of
levels. So just because domains render it obsolete doesn't make a TRACE
level invalid, just redundant.
TRACE is common enough that it just "looks bad" that log4j doesn't have it.
So while I don't see a real need for it, I am slightly in favor of it
primarily for reasons of helping the way log4j is perceived -- justified or
not.
-Jim Moore
----- Original Message -----
From: "Ceki Gülcü" <ce...@qos.ch>
To: "Log4J Developers List" <lo...@logging.apache.org>
Sent: Friday, March 12, 2004 10:30 AM
Subject: [VOTE] Adding the TRACE level
Hi All,
The issue has been discussed several times in the log4j mailing lists
and great many users have asked for it. Consequently, here is a formal
vote to include the TRACE level.
[ ] +1, Yes, the TRACE would be a useful addition
[ ] 0, I don't care
[ ] -1, No, TRACE should not be included
I would like to vote -1 due to the following arguments:
- Many people use INFO and DEBUG for development, eliminating the need
for TRACE. One uses DEBUG to output chatty information and INFO to
output an overview the application's progress.
- The next version of log4j will introduce the concept of domains
allowing developers to log by multiple criteria, thus creating a much
more powerful way of categorizing (i.e. classifying) logging
statements, thus dispensing with the need to use various new levels
(e.g. the trace level) to express logging/filtering criteria. With the
introduction of domains the trace level will look like what it really
is, a common but nonetheless a lame hack.
- It is possible to wrap the Logger class and extend the Level class to
include support for the trace level.
- Moreover, The generic log() method in the Logger class takes in a
Level as its first parameter. This allows the developer to log at
any level, including the trace level. For example:
Logger logger = Logger.getLogger("some.logger.name");
logger.log(XLevel.TRACE, "some message");
where [XLevel] class extends the Level class by adding the trace
level. There is a section about in the FAQ as well:
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceLevel
Although typing in this method call is slightly longer than typing the
usual printing methods such as logger.debug("message") or
logger.info("message"), modern IDEs can easily automate the process.
Given that code changes require lazy consensus, this veto kills the
vote right in the bud. Note this is the usual procedure for reaching a
decision at Apache. At the same time, it does not seem right to me
that a single individual should be able to overrule everyone else,
especially if that person happens to be me.
Maybe we should change the Logging Services bylaws to demand a 2/3
majority or just a simple majority instead of lazy consensus for code
changes. What do you guys think?
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
[VOTE] Adding the TRACE level
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi All,
The issue has been discussed several times in the log4j mailing lists
and great many users have asked for it. Consequently, here is a formal
vote to include the TRACE level.
[ ] +1, Yes, the TRACE would be a useful addition
[ ] 0, I don't care
[ ] -1, No, TRACE should not be included
I would like to vote -1 due to the following arguments:
- Many people use INFO and DEBUG for development, eliminating the need
for TRACE. One uses DEBUG to output chatty information and INFO to
output an overview the application's progress.
- The next version of log4j will introduce the concept of domains
allowing developers to log by multiple criteria, thus creating a much
more powerful way of categorizing (i.e. classifying) logging
statements, thus dispensing with the need to use various new levels
(e.g. the trace level) to express logging/filtering criteria. With the
introduction of domains the trace level will look like what it really
is, a common but nonetheless a lame hack.
- It is possible to wrap the Logger class and extend the Level class to
include support for the trace level.
- Moreover, The generic log() method in the Logger class takes in a
Level as its first parameter. This allows the developer to log at
any level, including the trace level. For example:
Logger logger = Logger.getLogger("some.logger.name");
logger.log(XLevel.TRACE, "some message");
where [XLevel] class extends the Level class by adding the trace
level. There is a section about in the FAQ as well:
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceLevel
Although typing in this method call is slightly longer than typing the
usual printing methods such as logger.debug("message") or
logger.info("message"), modern IDEs can easily automate the process.
Given that code changes require lazy consensus, this veto kills the
vote right in the bud. Note this is the usual procedure for reaching a
decision at Apache. At the same time, it does not seem right to me
that a single individual should be able to overrule everyone else,
especially if that person happens to be me.
Maybe we should change the Logging Services bylaws to demand a 2/3
majority or just a simple majority instead of lazy consensus for code
changes. What do you guys think?
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: TRACE!!! (Was: Re: Log4j Domains - Volunteer)
Posted by Ceki Gülcü <ce...@qos.ch>.
At 04:26 PM 3/11/2004 +1100, Paul Smith wrote:
> > So, what was the verdict?
>I can't get into what the verdict is as I can't remember. By the sounds
>of things, all us log4j-dev guys are:
>
>a) Barely keeping our heads above water, work-wise
>b) Recovering from surgery
>
>Hi Gier,
>
>c) all of the above
>
>[(a) for me anyway]
It's (c) for me. :-)
>Should there be a vote in the future, I can say my intention would be to
>vote +1 on the concept of adding TRACE. However I can't comment on any
>implementation details that have been discussed so far as I've been too
>busy to focus on it (I wouldn't use TRACE, personally).
I think implementation is not the mean issue but rather the question
of whether including TRACE or not. I am inclined to vote against it,
based on the arguments listed at:
http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/TraceDebate
At the same time, it seems to me that voting on the subject and thus
following through with the democratic decision process carries more
weight than any other technical consideration.
So let's vote each according to our best judgement.
I'll follow up with a vote proposal.
>Hope everyone is well.
>
>cheers,
>
>Paul Smith
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: TRACE!!! (Was: Re: Log4j Domains - Volunteer)
Posted by Paul Smith <pa...@lawlex.com.au>.
> >
> > All we need is someone to propose the changes to they can be reviewed
> > (not
> > torn apart as Endre says) and voted on. The change should be backward
> > compatible.
>
> So, what was the verdict?
Hi Gier,
I can't get into what the verdict is as I can't remember. By the sounds
of things, all us log4j-dev guys are:
a) Barely keeping our heads above water, work-wise
b) Recovering from surgery
c) all of the above
[(a) for me anyway]
Should there be a vote in the future, I can say my intention would be to
vote +1 on the concept of adding TRACE. However I can't comment on any
implementation details that have been discussed so far as I've been too
busy to focus on it (I wouldn't use TRACE, personally).
Hope everyone is well.
cheers,
Paul Smith
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org