<?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: Which jar contains my&#8230;</title>
	<atom:link href="http://www.isocra.com/2006/02/jarfinder/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.isocra.com/2006/02/jarfinder/</link>
	<description>Thoughts and tutorials on web design, Java, Javascript and project management</description>
	<lastBuildDate>Wed, 01 Feb 2012 09:44:07 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Charlie</title>
		<link>http://www.isocra.com/2006/02/jarfinder/comment-page-1/#comment-2909</link>
		<dc:creator>Charlie</dc:creator>
		<pubDate>Tue, 03 Jan 2012 17:33:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.isocra.com/new/2006/02/jarfinder/#comment-2909</guid>
		<description>I ran into a problem with a directory that was named *.jar.  This is a valid name for a directory, but it caused a ZipFile exception.

I fixed the problem in EntryVisitor.java by testing for the File being a directory first.  The code in method searchDir() now looks like this:
&lt;pre&gt;
        for (int i = 0; i &lt; files.length; i++) {
            File file = files[i];
            if (file.isDirectory()) {
                // It&#039;s a directory , so call ourselves recursively
                this.searchDir(file);
            } else if (isJar(file)) {
                // It&#039;s a jar
                this.searchJar(file);
            } else {
                // If it&#039;s any other sort of file, visit it anyway
                visit(file);
            }
        }
&lt;/pre&gt;</description>
		<content:encoded><![CDATA[<p>I ran into a problem with a directory that was named *.jar.  This is a valid name for a directory, but it caused a ZipFile exception.</p>
<p>I fixed the problem in EntryVisitor.java by testing for the File being a directory first.  The code in method searchDir() now looks like this:</p>
<pre>
        for (int i = 0; i &lt; files.length; i++) {
            File file = files[i];
            if (file.isDirectory()) {
                // It&#039;s a directory , so call ourselves recursively
                this.searchDir(file);
            } else if (isJar(file)) {
                // It&#039;s a jar
                this.searchJar(file);
            } else {
                // If it&#039;s any other sort of file, visit it anyway
                visit(file);
            }
        }
</pre>
]]></content:encoded>
	</item>
	<item>
		<title>By: denish</title>
		<link>http://www.isocra.com/2006/02/jarfinder/comment-page-1/#comment-9</link>
		<dc:creator>denish</dc:creator>
		<pubDate>Tue, 29 Jan 2008 22:18:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.isocra.com/new/2006/02/jarfinder/#comment-9</guid>
		<description>Unfortunately I don&#039;t thing it will work in application servers because they don&#039;t use the classpath for the actual applications. They use specific class loaders that dynamically load jars from WEB-INF/lib, or whereever.

However, have a look at the code in this post &lt;a href=&quot;http://www.isocra.com/2007/10/jndi-problems-with-tomcat-5515/&quot; rel=&quot;nofollow&quot;&gt;JNDI problems with Tomcat&lt;/a&gt;. If you look at the second code block you can see some code that loads a class and then tries to find where it was loaded from by getting the source code for the class and then the location for that. This definitely works with Tomcat (as long as the classes have been compiled with enough debugging information which is normally the case).</description>
		<content:encoded><![CDATA[<p>Unfortunately I don&#8217;t thing it will work in application servers because they don&#8217;t use the classpath for the actual applications. They use specific class loaders that dynamically load jars from WEB-INF/lib, or whereever.</p>
<p>However, have a look at the code in this post <a href="http://www.isocra.com/2007/10/jndi-problems-with-tomcat-5515/" rel="nofollow">JNDI problems with Tomcat</a>. If you look at the second code block you can see some code that loads a class and then tries to find where it was loaded from by getting the source code for the class and then the location for that. This definitely works with Tomcat (as long as the classes have been compiled with enough debugging information which is normally the case).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jacob</title>
		<link>http://www.isocra.com/2006/02/jarfinder/comment-page-1/#comment-8</link>
		<dc:creator>Jacob</dc:creator>
		<pubDate>Tue, 29 Jan 2008 21:24:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.isocra.com/new/2006/02/jarfinder/#comment-8</guid>
		<description>Does this work in tomcat and application servers in general?</description>
		<content:encoded><![CDATA[<p>Does this work in tomcat and application servers in general?</p>
]]></content:encoded>
	</item>
</channel>
</rss>

