<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Negative Engery</title>
	<atom:link href="http://www.symphonious.net/2007/04/01/negative-engery/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.symphonious.net/2007/04/01/negative-engery/</link>
	<description>Living in a state of accord.</description>
	<pubDate>Fri, 09 Jan 2009 11:07:28 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Adrian Sutton</title>
		<link>http://www.symphonious.net/2007/04/01/negative-engery/comment-page-1/#comment-68765</link>
		<dc:creator>Adrian Sutton</dc:creator>
		<pubDate>Mon, 02 Apr 2007 22:33:58 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2007/04/01/negative-engery/#comment-68765</guid>
		<description>If everyone used JDK logging I'd be fine with that, but there are a lot of apps out there that still use Log4J and would be annoyed if a tiny little library made them configure and use JDK logging as well. Having an abstraction layer is great for avoiding just that problem. The main reason JCL doesn't have a lot of development on it is because it has achieved it's aims and it just works. JCL has a very narrow focus of what it should do and they've been very careful to stick with that narrow focus. Hopefully in time it will become unnessecary but for now it seems to still be needed.</description>
		<content:encoded><![CDATA[<p>If everyone used JDK logging I&#8217;d be fine with that, but there are a lot of apps out there that still use Log4J and would be annoyed if a tiny little library made them configure and use JDK logging as well. Having an abstraction layer is great for avoiding just that problem. The main reason JCL doesn&#8217;t have a lot of development on it is because it has achieved it&#8217;s aims and it just works. JCL has a very narrow focus of what it should do and they&#8217;ve been very careful to stick with that narrow focus. Hopefully in time it will become unnessecary but for now it seems to still be needed.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Hen</title>
		<link>http://www.symphonious.net/2007/04/01/negative-engery/comment-page-1/#comment-68757</link>
		<dc:creator>Hen</dc:creator>
		<pubDate>Mon, 02 Apr 2007 17:49:23 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2007/04/01/negative-engery/#comment-68757</guid>
		<description>Why not just use the JDK logging? Are you having to support old JDKs?

My general thinking on the logging thing is that there should be a Lang 3.0 (JDK 1.5+) that wraps the JDK logging with a small facade for any usable helper bits that are needed.

--

JCL 1.1 is supposed to have cleaned the warts up, though I think that might have been the swansong for  the code as there's not much need for it once you leave old JDKs behind.</description>
		<content:encoded><![CDATA[<p>Why not just use the JDK logging? Are you having to support old JDKs?</p>
<p>My general thinking on the logging thing is that there should be a Lang 3.0 (JDK 1.5+) that wraps the JDK logging with a small facade for any usable helper bits that are needed.</p>
<p>&#8211;</p>
<p>JCL 1.1 is supposed to have cleaned the warts up, though I think that might have been the swansong for  the code as there&#8217;s not much need for it once you leave old JDKs behind.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Ceki Gulcu</title>
		<link>http://www.symphonious.net/2007/04/01/negative-engery/comment-page-1/#comment-68750</link>
		<dc:creator>Ceki Gulcu</dc:creator>
		<pubDate>Mon, 02 Apr 2007 13:32:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.symphonious.net/2007/04/01/negative-engery/#comment-68750</guid>
		<description>JCL's warts have been widely discussed in the past. Typically, when used in conjunction with Tomcat, JCL may transform actual errors in logging errors, significantly lengthening the time it takes to identify problems. 

While SLF4J offers several API enhancements over JCL, its robustness is its main differentiator. SLF4J's simplicity and robustness resonate very strongly with developers who have been bitten by JCL. For other developers who have not yet experienced problems with JCL, SLF4J may be perceived as anti-JCL. 

As you justly observe, logging is a controversial subject. I also agree with you that SLF4J would probably be better off by emphasizing its positive points rather than trashing JCL.</description>
		<content:encoded><![CDATA[<p>JCL&#8217;s warts have been widely discussed in the past. Typically, when used in conjunction with Tomcat, JCL may transform actual errors in logging errors, significantly lengthening the time it takes to identify problems. </p>
<p>While SLF4J offers several API enhancements over JCL, its robustness is its main differentiator. SLF4J&#8217;s simplicity and robustness resonate very strongly with developers who have been bitten by JCL. For other developers who have not yet experienced problems with JCL, SLF4J may be perceived as anti-JCL. </p>
<p>As you justly observe, logging is a controversial subject. I also agree with you that SLF4J would probably be better off by emphasizing its positive points rather than trashing JCL.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
