<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Feb 19, 2013, at 1:59 PM, Chris Burrell <<a href="mailto:christopher@burrell.me.uk">christopher@burrell.me.uk</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">I haven't come across this one before. I've come across an issue in Java 7 where it starts catering for INDEX.LIST files if they are packaged into jar dependencies whereupon it tries to get every dependency in there (the INDEX.LIST is located under META-INF).<div>
<br></div><div style="">But if you mean resources as in the ones under src/main/resources which end up on the classpath, I'm not entirely sure why they can't be found. </div><div style=""><br></div><div style="">Can it be anything to do with this: <a href="http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/faq.html#s211">http://docs.oracle.com/javase/7/docs/technotes/guides/javaws/developersguide/faq.html#s211</a></div></div></blockquote><div><br></div>Probably. Was looking at that before I posted this.</div><div><br><blockquote type="cite"><div dir="ltr">
<div style=""><br></div><div style="">The javadoc for pickLoader in CwClassLoader is a bit misleading in terms of it saying "returns true ..." but I'm not sure I really understand the logic. But I'm guessing it's getting the System classloader at some point in the chain, and then you end up not finding your resources?</div>
<div style=""><br></div><div style="">Why are we using our own classloader by the way?</div></div></blockquote><div><br></div><div>A simple example of how we use it and then an explanation of how it is useful:</div><div>In the jar for BibleDesktop, we have desktop.properties, which is the default set of properties for BibleDesktop.</div><div>The user can change these properties, so we save them to disk (under $JSWORD_HOME, which varies by OS. Under linux it is ~/.jsword and mac it is ~/Library/Application Support/JSword).</div><div><br></div><div>Now we have two files named desktop.properties. Rather than having a file lookup in $JSWORD_HOME and then a resource lookup in the jar, we have a single mechanism to do the lookup and we prefix $JSWORD_HOME to the lookup path for the classloader. This then provides merely a resource lookup as a singular mechanism to get the file.</div><div><br></div><div>The advantage of this is that any text file that is loaded by the CWClassLoader can now be overridden by dropping a copy of a file into $JSWORD_HOME. This file can be represented in several different ways:</div><div><br></div><div>If the class owning the resource InstallManager.plugin is org.crosswire.jsword.book.install.InstallManager, then the file can be any of the following:</div><div>$JSWORD_HOME/InstallManager.plugin</div><div>$JSWORD_HOME/org.crosswire.jsword.book.install.InstallManager.InstallManager.plugin</div><div>$JSWORD_HOME/org/crosswire/jsword/book/install/InstallManager/InstallManager.plugin</div><div>Then it looks in the jars on the classpath for the same.</div><div><br></div><div>I forget the lookup order, but it takes the first it finds. Let's just say that it is bad form to have it in two places locally.</div><div><br></div><div>Then editing the file allows for those values to take effect on next startup.</div><div><br></div><div>This is really useful to change logging levels by dropping CWLogging.properties into JAVA_HOME and setting it up the way you want. (So it is useful to developers to tweak JSword and not have those changes accidentally managed under source code control.)</div><div><br></div><div>Another example, the language Sorani was not being recognized as a right-to-left language (because the language was unknown to JSWORD). We could ship the end user an updated iso639.properties file for them to drop in JSWORD_HOME. And then it would work.</div><div><br></div><div>The disadvantage to all of this is that there is no reset button. The file takes precedence over all future updates to JSword. So when the program is updated to handle the work-around and perhaps to also provide new stuff, the file takes precedence.</div><div><br></div><div>We had the program launcher include $JSWORD_HOME on the classpath, but that didn't work well for all platforms as the path varies significantly on Windows from one OS version to the next and on one user setup to the next.</div><div><br></div><div>Since JSword is able to figure it out, it essentially adds the correct value of JSWORD_HOME to the classpath by providing its own classloader.</div><div><br></div><div>If I remember correctly, this mechanism was necessary to get WebStart to work, too. Now it doesn't work.</div><div><br></div><div>Clear as mud?</div><div><br></div><div>In Him,</div><div><span class="Apple-tab-span" style="white-space:pre"> </span>DM</div><div><br></div><blockquote type="cite"><div dir="ltr"><div style="">Chris</div><div style=""><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 19 February 2013 13:25, DM Smith <span dir="ltr"><<a href="mailto:dmsmith@crosswire.org" target="_blank">dmsmith@crosswire.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've always provided a way to run Bible Desktop directly from the web using Java Web Start.<br>
<br>
Now we're having problems. There's a change that prevents our code from finding resources. It appears that Java 7's Web Start is preventing our ClassLoader from loading resources.<br>
<br>
I'd greatly appreciate help finding this.<br>
<br>
I'm thinking it may be a problem in other contexts.<br>
<br>
The exact same code runs from the command line.<br>
<br>
In Him,<br>
DM<br>
<br>
<br>
<br>
_______________________________________________<br>
jsword-devel mailing list<br>
<a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/jsword-devel" target="_blank">http://www.crosswire.org/mailman/listinfo/jsword-devel</a><br>
</blockquote></div><br></div>
_______________________________________________<br>jsword-devel mailing list<br><a href="mailto:jsword-devel@crosswire.org">jsword-devel@crosswire.org</a><br>http://www.crosswire.org/mailman/listinfo/jsword-devel<br></blockquote></div><br></body></html>