Deane,
I checked in the new classloader stuff, and removed the
extensions.properties files. I accidentally got the desktop to work
again, but there may be url -> xml issues. The new classloader is
JNLPClassLoader. It's fairly clean, but I would like to get rid of the
getExtensionName and getExtensionHREF methods. I think this would
improve the DCF codes too, since they could just get the JNLPFile and
use that instead of getting each part seperately. Or the ExtensionName
should at least be unnecessary since it loads from a URL directly
instead of looking it up in a table. You mentioned that this might be
bad because the files might move, but it may be better because the local
system could now read 'documents' that were created on other systems
that 'knew about' more extensions than the local one, if a network
location for the extension was used there.
Anyway, it seems to work. It uses a really simple cache instead of
hooking into cachemgr (I didnt' know if cachmgr was thread safe and
there were enough potential problems to worry about!). I propose a new
cache policy, where instead of checking for and downloading new versions
immediately, apps are run with the old version in cache and then the new
version is downloaded while it is running, and used when the apps is
launched at a later time. This should dramatically increase startup
time... check out
http://www.gentleware.com/download/Poseidon4umlJWS.jnlp
for an example (have to turn off security to get it to work); it's got
~25 jars that used to be checked for being up-to-date each time it was
run, initial startup going from ~22 seconds (depending on trans-Atlantic
congestion) from the cache to ~1 second. Check out CacheUtil in jnlp
dir for where hooks into the cache would go.
Also I removed the IExtensionLoader interface to the classloader... if
code is hard-wired to the jnlp classloader it won't matter if it is
using an interface or class.
Jam
|
