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 Katherine Hale <ka...@gmail.com> on 2008/02/09 18:05:17 UTC
Varargs support to the sandbox
Hello! I have checked out the sandbox via SVN, I'm familiar with ANT & test
cases and all that good stuff. The readme said I should post here to
contribute. If anyone wants to send me information about exactly where to
submit a contribution that would be useful.
Thanks!
Kathy
Re: Varargs support to the sandbox
Posted by Curt Arnold <ca...@apache.org>.
On Feb 10, 2008, at 8:35 PM, Katherine Hale wrote:
> Curt -
>
> Thanks for the fly-by-night introduction. This is what I was
> thinking in more detail. Again I know this is Java 5, so this would
> be for Log4J 2.0, although perhaps something comparable could be
> devised for the current Log4J. I'll just use debug as an example.
>
> I find myself frequently logging like this...
>
> Logger.debug(String.format("First object '%s', second object '%s'",
> first, second));
>
> When I wish I could just be logging like this..
>
> Logger.debug("First object '%s', second object '%s'", first, second);
>
> The new signature I feel is missing would be something like this...
>
> public static debug(String message, String ... arguments)
>
> After briefly looking at LogMF, this might be doing the same thing.
> I'm not familiar with MessageFormat, so I don't know if the usage
> for the "pattern" argument is the same or different from
> String.format() in Java 5.
>
> 352 /***
> 353 * Log a parameterized message at debug level.
> 354 * @param logger logger, may not be null.
> 355 * @param pattern pattern, may be null.
> 356 * @param arguments an array of arguments to be formatted and
> substituted.
> 357 */
> 358 public static void debug(final Logger logger, final String
> pattern,
> 359 final Object[] arguments) {
> 360 if (logger.isDebugEnabled()) {
> 361 forcedLog(logger, Level.DEBUG, format(pattern, arguments));
> 362 }
> 363 }
>
>
> Thoughts?
>
String.format() is an indirect call to the java.util.Formatter class
that was introduced in JDK 1.5. The LogF class that was started at
the same time as LogMF and LogSF but not driven through to release
used java.util.Formatter. It is still in the SVN history and could be
brought forward, but LogSF and LogMF were more immediately useful.
LogSF was provided as a migration path for the log4j 1.3 message
formatter which had a syntax similar to, but incompatible with with
java.text.MessageFormat. There is no reason to use LogSF in new code.
Your logging statement could look like:
LogMF.debug(logger, "First object '{0}', second object '{1}'", first,
second);
or
LogF.debug(logger, "First object '%s', second object '%s'", first,
second);
Since there are two distinct formatters provided in the JDK, it would
be undesirable for log4j to pick one over the other (or worse yet to
introduce yet another pattern syntax).
LogMF avoids the construction of the Object[] array until the
threshold is evaluated which a varargs approach would not do unless
the JVM was able to detect the array was not going to be used.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Varargs support to the sandbox
Posted by Katherine Hale <ka...@gmail.com>.
Curt -
Thanks for the fly-by-night introduction. This is what I was thinking in
more detail. Again I know this is Java 5, so this would be for Log4J 2.0,
although perhaps something comparable could be devised for the current
Log4J. I'll just use debug as an example.
I find myself frequently logging like this...
Logger.debug(String.format("First object '%s', second object '%s'", first,
second));
When I wish I could just be logging like this..
Logger.debug("First object '%s', second object '%s'", first, second);
The new signature I feel is missing would be something like this...
public static debug(String message, String ... arguments)
After briefly looking at LogMF, this might be doing the same thing. I'm not
familiar with MessageFormat, so I don't know if the usage for the "pattern"
argument is the same or different from String.format() in Java 5.
352<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#352>
*/****
353<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#353>
* * Log a parameterized message at debug level.*
354<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#354>
* * @param logger logger, may not be null.*
355<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#355>
* * @param pattern pattern, may be null.*
356<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#356>
* * @param arguments an array of arguments to be formatted and substituted.*
357<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#357>
* */*
358<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#358>
*public* *static* *void* debug(*final* Logger logger, *final* String
pattern,
359<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#359>
*final* Object[] arguments) {
360<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#360>
*if* (logger.isDebugEnabled()) {
361<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#361>forcedLog(logger,
Level.DEBUG, format(pattern, arguments));
362<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#362>}
363<http://logging.apache.org/log4j/companions/extras/xref/org/apache/log4j/LogMF.html#363>}
Thoughts?
Kathy
On Feb 9, 2008 3:59 PM, Curt Arnold <ca...@apache.org> wrote:
>
> On Feb 9, 2008, at 11:05 AM, Katherine Hale wrote:
>
> > Hello! I have checked out the sandbox via SVN, I'm familiar with ANT
> > & test cases and all that good stuff. The readme said I should post
> > here to contribute. If anyone wants to send me information about
> > exactly where to submit a contribution that would be useful.
> >
> > Thanks!
> >
> > Kathy
>
> The best approach is to discuss your ideas, requirements, plans,
> possible contribution etc on the mailing list before starting to
> code. The ASF is all about community developed software, it is much
> preferable to start with openly discussed ideas and then code then to
> drop a substantial body of code and expect the community try to
> comprehend it. It is very helpful to have the design discussions on
> the mailing list for future reference. There are some parts of log4j
> that were dropped in without any prior discussion which makes them
> hard to support and enhance.
>
> Have you looked at LogMF in the extras companion? LogMF provides a
> static utility class to prepare logging requests using
> java.text.MessageFormat. The signatures of LogMF were designed to
> offer vararg like behavior to users of JDK's prior to JDK 1.5 and can
> take advantage of varargs with JDK 1.5 and later if you hit a pattern
> that wasn't supported. LogSF is like LogMF, but uses a formatter
> similar to that provided in the discontinued log4j 1.3 development.
>
> There had been a LogF in the sandbox earlier that used
> java.util.Formatter which was introduced in JDK 1.5. Development was
> suspended, but it could be resurrected anytime there is interest.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
>
Re: Varargs support to the sandbox
Posted by Curt Arnold <ca...@apache.org>.
On Feb 9, 2008, at 11:05 AM, Katherine Hale wrote:
> Hello! I have checked out the sandbox via SVN, I'm familiar with ANT
> & test cases and all that good stuff. The readme said I should post
> here to contribute. If anyone wants to send me information about
> exactly where to submit a contribution that would be useful.
>
> Thanks!
>
> Kathy
The best approach is to discuss your ideas, requirements, plans,
possible contribution etc on the mailing list before starting to
code. The ASF is all about community developed software, it is much
preferable to start with openly discussed ideas and then code then to
drop a substantial body of code and expect the community try to
comprehend it. It is very helpful to have the design discussions on
the mailing list for future reference. There are some parts of log4j
that were dropped in without any prior discussion which makes them
hard to support and enhance.
Have you looked at LogMF in the extras companion? LogMF provides a
static utility class to prepare logging requests using
java.text.MessageFormat. The signatures of LogMF were designed to
offer vararg like behavior to users of JDK's prior to JDK 1.5 and can
take advantage of varargs with JDK 1.5 and later if you hit a pattern
that wasn't supported. LogSF is like LogMF, but uses a formatter
similar to that provided in the discontinued log4j 1.3 development.
There had been a LogF in the sandbox earlier that used
java.util.Formatter which was introduced in JDK 1.5. Development was
suspended, but it could be resurrected anytime there is interest.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org