RE: cvs commit: logging-log4j/tests/src/java/org/apache/log4j/helpers/mcomposer MessageComposerTest.java

[Paul Smith <ps...@aconex.com>]

>
> There are several reasons.
>
> 1) With MessageComposer one can write:
>
>    logger.debug("My name is {}.", name);
>    logger.debug("My name is {}. I am {} years old", name, age);
>
> instead of
>
>    logger.debug("My name is {0}.", name);
>    logger.debug("My name is {0}. I am {1} years old", name, age);
>
> with java.text.MessageFormat.
>

Actually, I was thinking along the lines of:

   logger.debug("My name is {1}. I am {0} years old", new Object[]{new
Integer(30}, "Paul"});

Which is more cryptic, no arguments there, but more flexible:

  * It can handle practically unlimited # of args
  * Order of args can be different from the order they are displayed.

> I think the omission of the numbered parameters makes writing debug
> statements quicker and easier for the user. You have to try it 4 or 5
> times to notice the difference but it becomes quite noticeable after a
> short while.
>

It would surely be easier to use, I cannot argue that, but, how many
arguments will we support? 2?  5? 10?  It seems limiting to me, despite the
ease of use.

Any comments on that?

> 2) Since MessageComposer has a smaller scope, it should perform its
> parsing duties significantly faster then java.text.MessageFormat.
> Moreover, since we have access to the internals of MessageComposer, we
> can modify it so that it caches its results. Thus, the next time a
> given message needs to be output, we can use the parsed structure and
> economize the work involved in parsing the message.
>

Yes, we (and by that I mean you... :) ) can probably do a better job of
implementing it.

cheers,

Paul Smith


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

RE: cvs commit: logging-log4j/tests/src/java/org/apache/log4j/helpers/mcomposer MessageComposerTest.java

[Elias Ross <er...@m-qube.com>]

On Tue, 2004-11-02 at 14:45, Paul Smith wrote:

> Actually, I was thinking along the lines of:
> 
>    logger.debug("My name is {1}. I am {0} years old", new Object[]{new
> Integer(30}, "Paul"});

I would support both "{}" and "{#}" formats.

In code that I write, I use this sort of construct:

class Example {
  Logger logger = ....
  LogText LT = LogText.get(getClass()); 
    // LogText contains a resource bundle

  void method() {
    logger.debug(LT.get("msg1", arg0, arg1));
  }

}
  
I allow up to 3, no more, no less.  (c.f "Monty Python and the Holy
Grail")  If you have more than 3, then the line is pretty big anyway.

This is really compact.

Couldn't you create a class called "MC" (shorted from MessageComposer)
that you could use like so?

import org.apache.log4j.helpers.MC;
import org.apache.log4j.Logger;

class Example {
  Logger logger = ....

  void method() {
    logger.debug(MC.format("Holy {0} {1}!", arg0, arg1));
  }

}
  
Then you wouldn't need to change Logger at all!


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org

RE: cvs commit: logging-log4j/tests/src/java/org/apache/log4j/helpers/mcomposer MessageComposerTest.java

[Ceki Gülcü <ce...@qos.ch>]

At 11:45 PM 11/2/2004, Paul Smith wrote:

>Actually, I was thinking along the lines of:
>
>    logger.debug("My name is {1}. I am {0} years old", new Object[]{new
>Integer(30}, "Paul"});
>
>Which is more cryptic, no arguments there, but more flexible:
>
>   * It can handle practically unlimited # of args

Good point. However, keep in mind:

1) the 'new Object[]' part creates a superfluous object, i.e the
object array itself. Avoiding the creation of these superfluous
objects was the reason for this whole exercise. It turns out that the
cost of 'new Object[]' is about 8 times cheaper than the cost of
multiple string concatenation.  So, while the 'new Object[]'
constitutes progress over naive string concatenation, it is not as good as
the "if(logger.debugEnabled()){...}" form, as explained in 2).

2) If more 3 or more arguments need to be handled, one can always write

if(logger.debugEnabled()) {
   logger.info("We can put "+here+" as many "+args+" as "+name+" wants.");
}

I consider the if(logger.debugEnabled()){...} form as readable (or as
cryptic) as the the 'new Object[]' form. It has the distinct advantage
of completely avoiding superfluous object creation.

>   * Order of args can be different from the order they are displayed.

I don't see any real added value in allowing different argument
ordering between those in the message pattern and those in the
argument array. IMHO, it just creates one more way for the user to
make a mistake.

>It would surely be easier to use, I cannot argue that, but, how many
>arguments will we support? 2?  5? 10?  It seems limiting to me, despite the
>ease of use.
>
>Any comments on that?

As mentioned previously, you can always write
if(logger.debugEnabled()){...} to handle 3 or more arguments.

In conclusion, I think that between the isXXXEnabled methods and the
printing methods taking one or two arguments plus a message pattern,
there is no need for the object array variant. Given the above, would
you agree?


>Paul Smith

-- 
Ceki Gülcü

      For log4j documentation consider "The complete log4j manual"
      http://www.qos.ch/shop/products/eclm/  



---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org