You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Craig R. McClanahan" <cr...@apache.org> on 2002/02/20 01:56:01 UTC
[VOTE] Logging 1.0 Release (again)
OK, the round of discussion last time around has triggered some
improvements in the pluggability of the Logging API. In particular, it is
now possible to plug your own factory class for Log instances, if you
don't want to use the default algorithm. (For backwards compatibility,
the default algorithm implements the logic that was in LogSource -- which
is now deprecated but remains for API compatibility reasons).
There are a number of suggested changes that are *not* included, and I
propose that we continue to not include them:
* Adding a generic "Level" concept (either as a unique class or
as a set of integer constants) to the Log interface.
* Adding a log(Level, String) method to the Log interface.
* Adding mechanisms to configure loggers through the Log interface.
Going down the path of implementing any of these in the commons logging
wrapper would violate the principle on which this API was designed, of
being a very thin facade over the facilities of multiple underlying
wrapper implementations.
Therefore, I propose the current code base (as currently available in the
20020219 nightly build) to be released as Commons Logging 1.0. I
volunteer to act as release manager, and will follow the standard Commons
release procedure as documented at:
http://jakarta.apache.org/commons/releases.html
----- Cut Here -----
I vote as follows on the proposed Commons Logging 1.0 Release:
[ ] +1 - I support this release and am willing to help
[ ] +0 - I support this release, but cannot assist
[ ] -0 - I don't support this release
[ ] -1 - I vote against this release (requires valid *technical*
reasoning)
----- Cut Here -----
Craig McClanahan
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Logging 1.0 Release (again)
Posted by James Strachan <ja...@yahoo.co.uk>.
> ----- Cut Here -----
> I vote as follows on the proposed Commons Logging 1.0 Release:
> [X] +1 - I support this release and am willing to help
> [ ] +0 - I support this release, but cannot assist
> [ ] -0 - I don't support this release
> [ ] -1 - I vote against this release (requires valid *technical*
> reasoning)
> ----- Cut Here -----
Though looking forward to 2.0 release when we can get rid of LogSource to
avoid future confusion :)
James
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Logging 1.0 Release (again)
Posted by Ted Husted <hu...@apache.org>.
> ----- Cut Here -----
> I vote as follows on the proposed Commons Logging 1.0 Release:
> [x] +1 - I support this release and am willing to help
> [ ] +0 - I support this release, but cannot assist
> [ ] -0 - I don't support this release
> [ ] -1 - I vote against this release (requires valid *technical*
> reasoning)
> ----- Cut Here -----
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Logging 1.0 Release (again)
Posted by Jason van Zyl <jv...@zenplex.com>.
+0
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jvanzyl@apache.org
http://tambora.zenplex.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Logging 1.0 Release (again)
Posted by Morgan Delagrange <md...@yahoo.com>.
+1
----- Original Message -----
From: "Craig R. McClanahan" <cr...@apache.org>
To: <co...@jakarta.apache.org>
Sent: Tuesday, February 19, 2002 6:56 PM
Subject: [VOTE] Logging 1.0 Release (again)
> OK, the round of discussion last time around has triggered some
> improvements in the pluggability of the Logging API. In particular, it is
> now possible to plug your own factory class for Log instances, if you
> don't want to use the default algorithm. (For backwards compatibility,
> the default algorithm implements the logic that was in LogSource -- which
> is now deprecated but remains for API compatibility reasons).
>
> There are a number of suggested changes that are *not* included, and I
> propose that we continue to not include them:
> * Adding a generic "Level" concept (either as a unique class or
> as a set of integer constants) to the Log interface.
> * Adding a log(Level, String) method to the Log interface.
> * Adding mechanisms to configure loggers through the Log interface.
>
> Going down the path of implementing any of these in the commons logging
> wrapper would violate the principle on which this API was designed, of
> being a very thin facade over the facilities of multiple underlying
> wrapper implementations.
>
> Therefore, I propose the current code base (as currently available in the
> 20020219 nightly build) to be released as Commons Logging 1.0. I
> volunteer to act as release manager, and will follow the standard Commons
> release procedure as documented at:
>
> http://jakarta.apache.org/commons/releases.html
>
>
>
>
> ----- Cut Here -----
> I vote as follows on the proposed Commons Logging 1.0 Release:
> [ ] +1 - I support this release and am willing to help
> [ ] +0 - I support this release, but cannot assist
> [ ] -0 - I don't support this release
> [ ] -1 - I vote against this release (requires valid *technical*
> reasoning)
> ----- Cut Here -----
>
> Craig McClanahan
>
>
>
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[LOGGING] Request for API change (was RE: [VOTE] Logging 1.0 Release (again))
Posted by Steven Caswell <st...@yahoo.com>.
I want to revisit one of the issues noted below. A couple of weeks
before the VOTE was posted I made a request for a couple of these. I
agree with not doing the third item (configuration) and can live without
the second (though arguments for the first are valid for this one as
well. But I believe not having the first is a serious drawback.
> There are a number of suggested changes that are *not*
> included, and I propose that we continue to not include them:
> * Adding a generic "Level" concept (either as a unique class or
> as a set of integer constants) to the Log interface.
> * Adding a log(Level, String) method to the Log interface.
> * Adding mechanisms to configure loggers through the Log interface.
>
> Going down the path of implementing any of these in the
> commons logging wrapper would violate the principle on which
> this API was designed, of being a very thin facade over the
> facilities of multiple underlying wrapper implementations.
>
The lack of a Level concept in the API makes abstraction of logging code
more difficult than it should be. For example, suppose I want to write
a method in a utility class that logs the contents of a Map. This might
look something like the following:
public static void logMap(Map mapToLog, Log logger, ??? level)
{
for(Iterator keys = map.keySet().iterator(); keys.hasNext();)
{
String key = (String) keys.next();
String value = (String) map.get(key);
if(level == TRACE) logger.trace(key + "=" + value);
else if(level == DEBUG) logger.trace(key + "=" + value);
else if(level == DEBUG) logger.debug(key + "=" + value);
else if(level == INFO) logger.info(key + "=" + value);
...etc for each level
}
}
The difficulty in this is how to identify the level. Without a level
concept in the API, the application is forced to invent its own, which
it shouldn't have to do. Or the application can defined multiple
versions of the method, one for each level.
I disagree that going down the level path would violate the thin façade
principle. In fact, the API has already introduced the level concept by
exposing different level methods (i.e., Log.isTraceenabled(),
Log.trace(), etc.). Adding a set of constants to consistently identify
levels would make the already-existing level concept more robust, And
would make significant isolation of logging code must more reasonable to
achieve.
Steven Caswell
stevencaswell@yahoo.com
a.k.a Mungo Knotwise of Michel Delving
"One ring to rule them all, one ring to find them..."
_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Logging 1.0 Release (again)
Posted by co...@covalent.net.
On Tue, 19 Feb 2002, Craig R. McClanahan wrote:
> * Adding mechanisms to configure loggers through the Log interface.
No need for that - passing attributes to the factory should be enough
for most common needs.
In time we'll need to document whatever attribute names are used
for different factories ( same as SAX feature names ).
> I vote as follows on the proposed Commons Logging 1.0 Release:
> [X] +1 - I support this release and am willing to help
> [ ] +0 - I support this release, but cannot assist
> [ ] -0 - I don't support this release
> [ ] -1 - I vote against this release (requires valid *technical*
> reasoning)
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>