<?xml version="1.0" encoding="iso-8859-1"?><!-- generator="b2evolution/2.4.5" -->
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:admin="http://webns.net/mvcb/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:content="http://purl.org/rss/1.0/modules/content/">
	<channel>
		<title>Technical Beef - - Latest comments</title>
		<link>http://blog.kornr.net/index.php?disp=comments</link>
		<description></description>
		<language>en-US</language>
		<docs>http://backend.userland.com/rss</docs>
		<admin:generatorAgent rdf:resource="http://b2evolution.net/?v=2.4.5"/>
		<ttl>60</ttl>
				<item>
			<title>In response to: Jdbc Jutsu Saves Heap Memory Against Wicket's Stateful Ajax</title>
			<pubDate>Thu, 20 May 2010 07:49:05 +0000</pubDate>
			<dc:creator>jazz [Visitor]</dc:creator>
			<guid isPermaLink="false">c218@http://blog.kornr.net/</guid>
			<description>i use the way named JDBCStore.But i find nothing from the table tomcat_sessions.what's the reason ?</description>
			<content:encoded><![CDATA[i use the way named JDBCStore.But i find nothing from the table tomcat_sessions.what's the reason ?]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/06/18/jdbc-jutsu-saves-heap-memory-against-wic#c218</link>
		</item>
				<item>
			<title>In response to: Tomcat, JSessionID, and subdomains...</title>
			<pubDate>Wed, 05 May 2010 09:31:52 +0000</pubDate>
			<dc:creator>Mahmoud Saleh [Visitor]</dc:creator>
			<guid isPermaLink="false">c213@http://blog.kornr.net/</guid>
			<description>so jessionid cannot be used with https?</description>
			<content:encoded><![CDATA[so jessionid cannot be used with https?]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/05/29/tomcat-jsessionid-and-subdomains#c213</link>
		</item>
				<item>
			<title>In response to: OSGI-fying the apache commons-logging API</title>
			<pubDate>Thu, 08 Apr 2010 12:43:56 +0000</pubDate>
			<dc:creator>nogunner [Member]</dc:creator>
			<guid isPermaLink="false">c196@http://blog.kornr.net/</guid>
			<description>Hi Toni,&lt;br /&gt;
&lt;br /&gt;
I hesitated somewhat to publish your comment, because it severely lacks arguments, and I think you're missing the big picture here. Anyway, it's not worth than some of the viagra-spam that sometimes pass the spam barrier, so I just let it.&lt;br /&gt;
&lt;br /&gt;
First, the point you mention was already discussed there: http://blog.kornr.net/index.php/2008/12/18/osgi-logging-putting-it-all-together (read the comments please)&lt;br /&gt;
&lt;br /&gt;
I'm not sure why you're aggressively defending Pax Logging, which is not a bad solution except it fragments _again_ the logging frameworks used by the java community, which by itself is enough to keep it at bay, but what really bothered me was all the FUD the PAX initiative seemed to use in order to justify their solution. From what I can see, bad habits are not lost.&lt;br /&gt;
&lt;br /&gt;
Regarding your argument &quot;it creates fat &quot;self contained&quot; bundles, sweeping out the entire service layer and replacing it with monotholic (I suppose you mean &quot;monolithic&quot;, right?) uber bundles&quot;, it only shows you have not correctly understood what commons-logging is: it's not just a logging framework, it's also designed to be a _facade_ for a logging system that you can define at runtime. Let me put some emphasis on this: FACADE. I'm pretty sure you know how the facade pattern works, and why it makes sense to keep this facade because, well, it's widely used and can be considered a de facto standard. &lt;br /&gt;
&lt;br /&gt;
It's straightforward to keep the commons-logging facade (that's 2 classes, Log and LogFactory), and just change the code behind to call the the OSGi Log Service instead of the normal commons-logging engine that is available by default. That's what the sample code I provide (2 classes, 6Kb in total, is that what you call fat?) do. Nothing more. The benefit of that is that only one logging API is used (read facade), and a common code base can be shared between OSGi and non-OSGi projects.&lt;br /&gt;
&lt;br /&gt;
Now, please read the article I mentionned above, and if you have any suggestion for a better solution (and I'm sure there are), please do not hesitate to give a pointer. Pax Logging is not what _I_ call a better solution, but I'm not offended if it is for others. Just, please, stop the FUD, I'm sure you can make up better arguments than that to convince people to use your PAX stuff.&lt;br /&gt;</description>
			<content:encoded><![CDATA[Hi Toni,<br />
<br />
I hesitated somewhat to publish your comment, because it severely lacks arguments, and I think you're missing the big picture here. Anyway, it's not worth than some of the viagra-spam that sometimes pass the spam barrier, so I just let it.<br />
<br />
First, the point you mention was already discussed there: http://blog.kornr.net/index.php/2008/12/18/osgi-logging-putting-it-all-together (read the comments please)<br />
<br />
I'm not sure why you're aggressively defending Pax Logging, which is not a bad solution except it fragments _again_ the logging frameworks used by the java community, which by itself is enough to keep it at bay, but what really bothered me was all the FUD the PAX initiative seemed to use in order to justify their solution. From what I can see, bad habits are not lost.<br />
<br />
Regarding your argument "it creates fat "self contained" bundles, sweeping out the entire service layer and replacing it with monotholic (I suppose you mean "monolithic", right?) uber bundles", it only shows you have not correctly understood what commons-logging is: it's not just a logging framework, it's also designed to be a _facade_ for a logging system that you can define at runtime. Let me put some emphasis on this: FACADE. I'm pretty sure you know how the facade pattern works, and why it makes sense to keep this facade because, well, it's widely used and can be considered a de facto standard. <br />
<br />
It's straightforward to keep the commons-logging facade (that's 2 classes, Log and LogFactory), and just change the code behind to call the the OSGi Log Service instead of the normal commons-logging engine that is available by default. That's what the sample code I provide (2 classes, 6Kb in total, is that what you call fat?) do. Nothing more. The benefit of that is that only one logging API is used (read facade), and a common code base can be shared between OSGi and non-OSGi projects.<br />
<br />
Now, please read the article I mentionned above, and if you have any suggestion for a better solution (and I'm sure there are), please do not hesitate to give a pointer. Pax Logging is not what _I_ call a better solution, but I'm not offended if it is for others. Just, please, stop the FUD, I'm sure you can make up better arguments than that to convince people to use your PAX stuff.<br />]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2008/12/14/osgi-fying-the-apache-commons-logging-ap#c196</link>
		</item>
				<item>
			<title>In response to: OSGI-fying the apache commons-logging API</title>
			<pubDate>Thu, 08 Apr 2010 10:03:15 +0000</pubDate>
			<dc:creator>Toni Menzel [Visitor]</dc:creator>
			<guid isPermaLink="false">c195@http://blog.kornr.net/</guid>
			<description>Hi,&lt;br /&gt;
&lt;br /&gt;
just found your blogs and complaints about Pax Logging. &lt;br /&gt;
Looking at your solution, i don't know if this is an april fool's joke or ment to be serious? Are you really saying that embedding the commons logging libs into each bundle is a solution?&lt;br /&gt;
What you showed here is counter-productive as it creates fat &quot;self contained&quot; bundles, sweeping out the entire service layer and replacing it with monotholic uber bundles.&lt;br /&gt;
I am not sure, maybe this article is too old (2008?) and does not reflect your current mindset anymore. (i hope so).&lt;br /&gt;
No offence, just blown away from spreading those code smells.&lt;br /&gt;
cheers,&lt;br /&gt;
Toni</description>
			<content:encoded><![CDATA[Hi,<br />
<br />
just found your blogs and complaints about Pax Logging. <br />
Looking at your solution, i don't know if this is an april fool's joke or ment to be serious? Are you really saying that embedding the commons logging libs into each bundle is a solution?<br />
What you showed here is counter-productive as it creates fat "self contained" bundles, sweeping out the entire service layer and replacing it with monotholic uber bundles.<br />
I am not sure, maybe this article is too old (2008?) and does not reflect your current mindset anymore. (i hope so).<br />
No offence, just blown away from spreading those code smells.<br />
cheers,<br />
Toni]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2008/12/14/osgi-fying-the-apache-commons-logging-ap#c195</link>
		</item>
				<item>
			<title>In response to: Tomcat, JSessionID, and subdomains...</title>
			<pubDate>Fri, 05 Mar 2010 01:20:11 +0000</pubDate>
			<dc:creator>Karen [Visitor]</dc:creator>
			<guid isPermaLink="false">c154@http://blog.kornr.net/</guid>
			<description>Heman,&lt;br /&gt;
&lt;br /&gt;
No you can't use this solution with different domains. A JSESSIONID is just an HTTP cookie and HTTP cookies can't be shared with different domains (browser will not send cookies to different domains).</description>
			<content:encoded><![CDATA[Heman,<br />
<br />
No you can't use this solution with different domains. A JSESSIONID is just an HTTP cookie and HTTP cookies can't be shared with different domains (browser will not send cookies to different domains).]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/05/29/tomcat-jsessionid-and-subdomains#c154</link>
		</item>
				<item>
			<title>In response to: Someone out there is a total moron</title>
			<pubDate>Wed, 18 Nov 2009 22:06:41 +0000</pubDate>
			<dc:creator>L [Visitor]</dc:creator>
			<guid isPermaLink="false">c126@http://blog.kornr.net/</guid>
			<description>It was done on purpose to confuse the issue from what I've understood.</description>
			<content:encoded><![CDATA[It was done on purpose to confuse the issue from what I've understood.]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/01/15/someone-out-there-is-a-total-moron#c126</link>
		</item>
				<item>
			<title>In response to: Announcing Swit 0.9.0</title>
			<pubDate>Mon, 21 Sep 2009 07:41:51 +0000</pubDate>
			<dc:creator>&#221;&#241;&#242;&#238;&#237;&#234;&#224; [Visitor]</dc:creator>
			<guid isPermaLink="false">c124@http://blog.kornr.net/</guid>
			<description>&amp;#196;&amp;#224;&amp;#237;&amp;#237;&amp;#224;&amp;#255; &amp;#239;&amp;#243;&amp;#225;&amp;#235;&amp;#232;&amp;#234;&amp;#224;&amp;#246;&amp;#232;&amp;#255; &amp;#232;&amp;#236;&amp;#229;&amp;#229;&amp;#242; &amp;#237;&amp;#229;&amp;#244;&amp;#238;&amp;#240;&amp;#236;&amp;#224;&amp;#235;&amp;#252;&amp;#237;&amp;#251;&amp;#233;, &amp;#232;&amp;#237;&amp;#244;&amp;#238;&amp;#240;&amp;#236;&amp;#224;&amp;#242;&amp;#232;&amp;#226;&amp;#237;&amp;#251;&amp;#233; &amp;#241;&amp;#242;&amp;#232;&amp;#235;&amp;#252;, &amp;#225;&amp;#238;&amp;#235;&amp;#252;&amp;#248;&amp;#238;&amp;#229; &amp;#241;&amp;#239;&amp;#224;&amp;#241;&amp;#232;&amp;#225;&amp;#238; &amp;#194;&amp;#224;&amp;#236;!</description>
			<content:encoded><![CDATA[&#196;&#224;&#237;&#237;&#224;&#255; &#239;&#243;&#225;&#235;&#232;&#234;&#224;&#246;&#232;&#255; &#232;&#236;&#229;&#229;&#242; &#237;&#229;&#244;&#238;&#240;&#236;&#224;&#235;&#252;&#237;&#251;&#233;, &#232;&#237;&#244;&#238;&#240;&#236;&#224;&#242;&#232;&#226;&#237;&#251;&#233; &#241;&#242;&#232;&#235;&#252;, &#225;&#238;&#235;&#252;&#248;&#238;&#229; &#241;&#239;&#224;&#241;&#232;&#225;&#238; &#194;&#224;&#236;!]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/06/25/announcing-swit-0-9#c124</link>
		</item>
				<item>
			<title>In response to: Announcing Swit 0.9.0</title>
			<pubDate>Sun, 20 Sep 2009 01:58:43 +0000</pubDate>
			<dc:creator>Nick [Visitor]</dc:creator>
			<guid isPermaLink="false">c123@http://blog.kornr.net/</guid>
			<description>Very cool stuff.</description>
			<content:encoded><![CDATA[Very cool stuff.]]></content:encoded>
			<link>http://blog.kornr.net/index.php/2009/06/25/announcing-swit-0-9#c123</link>
		</item>
			</channel>
</rss>
