Excellent, I'll look into that. Thank you, Gary
On Fri, Sep 28, 2012 at 4:26 PM, Ralph Goers <[email protected]>wrote: > You didn't even consider what I would think would be the obvious solution > with Log4j 2. > > logger.debug(new MapMessage(System.getProperties()); > > but that doesn't work because System.getProperties() returns a Properties > object which extends Map<Object, Object> where the MapMessage constructor > requires Map<String, String>. Still, I would focus on a > SystemPropertiesMessage or add MapMessage(Map<Object, Object> map) to the > MapMessage before doing all the stuff you have below. Manipulating the > objects to be logged is exactly what Messages are for. > > > Ralph > > > On Sep 28, 2012, at 12:54 PM, Gary Gregory wrote: > > Hi All: > > [Preface: Some of this might seem heretic to the purist but it comes from > pragmatic experience of working with a lot of code from a lot of different > folks] > > For most of my Java apps, in DEBUG mode, I log the system properties at > some point on start up. > > The cheap solution is the obvious: > > logger.debug(System.getProperties()); > > The same idea applies, depending on my app for network interfaces and > character sets. > > Having one giant line is not easy to read, even in a word-wrapped editor. > > What I do instead is log one message per map entry. > > I go even further and explode the entries like the classpath (but let's > KISS for now.) > > This works great for the console and files but I can imagine that this > would be suboptimal for JMS. As always, caveat emptor. > > Could Log4J 2.0 do something like this? > > *Part 1:* > > It is tempting to add methods like: > > /** Logs one message per map entry in the form "key = value". */ > *debugMap*(Map<?, ?> map) > *debugMap*(Map<?, ?> map, String separator) > > *Part 2:* > > I then wonder how we could handle the explosion of map entries with some > kind of callback. > > Even if we did not, and the explosion was handled in the app itself, I > would like to be able to log my exploded messages in one go with a > collection like method: > > /** Logs one message per Iterable value. */ > *debugAll*(Iterable<?> iterable) > > *Part 3:* > > Back to exploding an object. This seems best handled in app code because > even with some callback, all the code in the app, so nothing is gained. > > Thoughts? > > *Part 4:* > > This is lame: > > logger.debug(NetworkInterface.getNetworkInterfaces()); > > It outputs: > > 15:47:44.624 [main] DEBUG org.apache.logging.log4j.core.BasicLoggingTest - > java.net.NetworkInterface$1@1ccce3c > > I would rather call: > > /** Logs one message per Enumeration value. */ > *debugAll*(Enumeration<?> enumeration) > > Whatever Log4J can do for me to help me DEBUG apps without my needing add > util code over and over. > > *Part 5:* > > Most folks might not need this, but we do: > > logger.debug(Charset.availableCharsets()); > > If I have *debugMap*, then it's pretty. > > Thank you reading this *far*! > > Gary > > -- > 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 > > > -- 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
