On Sun, Jul 15, 2012 at 11:27 AM, Ralph Goers <[email protected]>wrote:
> Changing the topic since this discussion isn't really related to the > release vote. > > On Jul 15, 2012, at 7:36 AM, Gary Gregory wrote: > > On Sun, Jul 15, 2012 at 10:13 AM, Ralph Goers > <[email protected]>wrote: > >> On Jul 15, 2012, at 6:36 AM, Gary Gregory wrote: >> >> Hi All: >> >> I've only now been able to take a peek at v2 in SVN so... sorry for the >> late email but I feel better late than never. >> >> With log4j 1.2, my usage pattern is: >> >> logger.debug(String.format("This %s and that %d on this day %1$tm >> %1$te,%1$tY", this, this.getThat(), this.getCalendar())); >> >> In 2.0, we have this example: >> >> logger.debug("Logging in user {} with id {}", user.getName(), >> user.getId()); >> >> Why invent a new syntax when String.format is baked into the JRE? >> >> >> Because you are doing the string formatting whether the log event will be >> logged or not, which means your logger.debug should always be wrapped in an >> if isDebugEnabled. Also, the current syntax is compatible with SLF4J. See >> http://www.slf4j.org/faq.html#logging_performance. >> > > Good discussion :) > > Yes, of course, I left the if/is* code out for brevity, it is not the > point of my discussion. I plan on leaving my if/is code in place even > if/when I move to log4j 2.0, it's just faster to call one API with no args > than the alternative. ;) > > I'm baffled by the SLF4J comment. > > > Because SLF4J is now widely adopted as a standard Logging API. Efficiently > supporting what it does out of the box is a good thing IMO. > > > I am a log4j 1.2 user, and I want to move to 2.0, so I have to learn the > SLF4J syntax instead of what is baked in the JRE to use this great new > feature? Bleh. That seems backwards to me. If we are trying to get people > to migrate from SLF4J to Log4J, then we could make that possible with > another option instead of baking it in the product. > > > No - you don't have to. As your example shows Log4j 1.x doesn't even > support parameterized messages. Just keep doing what you are doing. > I can keep on going my way of course but I would like to use a baked in API instead of layering my calls on top of the logging API. That would feel cleaner, but I'd still like a rich way to format messages. I understand the trade off now. Thank you for explaining it. It's not until I port all of our code to 2.0 that I'll see what I am missing WRT message formatting, so we'll see. What I am worried about is that lack of "named" arguments for i18n support. With the current {} format, you cannot re-order parameters. Using the JUL format of {0}, {1} and so on solves this issue. I do not know enough about the 2.0 API to know if this is an issue. Can I use the message as a key into a resource bundle and use the value as a format string? But I'd still need to re-order arguments because different languages order words in sentences differently. Am I missing something. Tangent: One rumor I hear behind the delay for version 5 of Hibernate is that they decided to write their own logging framework to properly do i18n, which is supposedly a requirement to use the software in some countries they care about. Gary > > > I could see that the String format should be pluggable (if that's a word). > IMO the default should be the JRE with a plugin for formats from other > products. > > > Not if it is 10 times slower than the SLF4J syntax. > > > I am not a JUL user but some of our customers are, how does the JUL syntax > compare with SLF4J? If it is not the same, it's going to be confusing! They > both use { and }. Blech. > > > I haven't even provided the JUL adapter for Log4j 2 yet. AFAIK there are > only two ways to do it and they both suck. > > > >> If you want to write your debug message the way you have shown there is >> nothing that says you can't. It will still work. However, as I recall Ceki >> ran tests that showed the Java text formatting is pretty slow. See >> http://bugzilla.slf4j.org/show_bug.cgi?id=116 for a nice discussion on >> this, and related topics. >> > > Is that still true in the latest Java 6 and 7? All of our customers are > on Java 6 FWIW. Does SLF4J and String.format have the same features? Is > that even comparing apples to apples? > > > I'm about to leave for the airport so I can't check right now, but my > expectation is that when I look at String.format I am going to find a > MessageFormat in it. But no, comparing SLF4J's formatting syntax to Java's > String formatting syntax is not comparing apples to apples, which is > precisely why SLF4J's performs so much better. It is simpler. > > > >> One other point. The String with placeholders is handled by >> ParamaterizedMessage. This class could either be extended or enhanced to >> support another syntax. If it is extended then that class would have to be >> used in the logging call such as >> >> logger.debug(new FormattedMessage("This %s and that %d on this day %1$tm >> %1$te,%1$tY", this, this.getThat(), this.getCalendar())); >> > > That is pretty heavy and provides no advantage over String.format IMO (I > use the if/is/log pattern). > > > Why is "new FormattedMessage" any heavier than "String.format". It does > have an advantage in that it is less expensive when you don't use > encapsulating ifs, which a lot of people would like to do without. > > > I want my config to say: use class foo to format the strings with args > then. What the default string format is then debatable. ;) > > > You would need to figure out a way to do that where it doesn't create a > real mess. Think about a commons project using that format while a > different piece of code uses the SLF4J format. How is the user supposed to > know how to deal with that? > > > -- E-Mail: [email protected] | [email protected] JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0 Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
