Force IE to reload applet jar without closing browser?
Hello,
We have an applet that we need to support with both the Sun plugin and the MS JVM in IE. We do releases weekly and need to make sure our users get the most recent version of the jar when they launch the applet after a release. With the plugin, we can do this by using the cache version tags that the plug in supports, but with the MS JVM it appears that unless the browser is closed and reopened, the user will get the cached version of the applet from the browser cache (or the running JVM?). How can I ensure that the browser will get the newer version without having the users reopen their browsers. Also, does anyone know what the problem is here? Where does the MS JVM cache the applet? Is it sitting around in the JVM and only when the brower is closed and JVM destroyed that you can get the new version? How does the MS JVM deal with caching applets?
BTW, I am not talking about making sure the HTML/applet tags arent cached, I dont think that is related to the jars being cached while the browser is still open.
Thanks
Aaron
[1071 byte] By [
ari11210a] at [2007-10-2 4:30:23]
Also, does anyone know how the Sun plugin deals with version caching (cache_version) when the 2nd request is made in the same browser session? For example, a user loads an applet for the 1st time, then the applet version is updated, and the users requests that applet a 2nd time without closing the browser. Assuming the HTML tags are correct and updated, will the plugin retrieve the correct version based on the cache_version tag?
Thanks again
aaron
The cache_version is not bound to the jar file on the server side. The plugin loads the jar once and stores it with the version number in the cache. If the cache_version in the applet tag is newer, the jar is being loaded directly and the cache updated. The plugin does not compare the client cache jar file to the jar on the server directly.
However, plugin caching only works for library jars. The jar which contains the applet class itself is always loaded directly. To optimize this, try to put the applet class in a separete jar file and store all the other helper classes (if you have any) in a separate jar for caching.
Thanks, but it appears that both the plugin and the MS JVM do not reload the new jar unless you restart the browser/JVM. For example, if I load an applet and the cache_version is 1.1 and then update the applet jar and cache_version tag to 1.2 and load the applet again without restarting the browser, I will get the old version. Perhaps it is still loaded into the JVM so it doesnt bother reloading it?
Thanks
Aaron
> Thanks, but it appears that both the plugin and the MS JVM do not reload the
> new jar unless you restart the browser/JVM.
Correct. When you restart browser and invoke something that triggers Java (e.g, applet, JS calls to Java), JPI will get loaded into the new browser instance. JPI's life remains the same as browser session's life.
During the JPI life, unless you clear the JPI ClassLoader (go to Java Console and type 'x'), otherwise, the same ClassLoader will be reused each time you refresh or reload your applet. We did this to improve performance. Because of ClassLoader reuse, jar once loaded, will remain in effect.
dp
dnpa at 2007-7-15 23:59:48 >
Thanks dnp for your response. So, even if the html object tags change (such as the cache_version) and there is a new version of the jar on the server, the plugin will still use the class/jar that was previously loaded?
We have an issue where our users don't restart their browsers over the weekend when we do new releases and end up with outdated jars. Anyway around this without asking them to restart the browser?
Thanks again
Aaron
Also, we are considering renaming the jars with each release to avoid this issue. Would you agree that this should solve it? Or is the plugin going to realize that the class names are the same?ThanksAaron
> So, even if the html object tags change (such as the cache_version) and >there is a new version of the jar on the server, the plugin will still use the >class/jar that was previously loaded?
We allow pre-loading of jar files by HTML parameter called cache_archive_ex. This parameter allows one to specify whether the jar file needs to be pre-loaded. Optionally the version of the jar file can also be specified. The version number format is what suit your need and when search for new/old, JPI use lexical order. The value of cache_archive_ex has the following format
cache_archive_ex = "<jar file name>;<preload(optional)>;<jar file version(optional)>,<jar file name>;<preload(optional)>;<jar file version(optional)>,....
The optional tags like preload or the jar file version can appear after the jar file name in any order seperated by the delimiter ';'.
Following HTML tag describes the various parameters,
<OBJECT .... >
<PARAM NAME="archive" VALUE="a.jar">
<PARAM NAME="cache_archive" VALUE="b.jar, c.jar, d.jar">
<PARAM NAME="cache_version" VALUE="0.0.0.1, 0.0.A.B, 0.A.B.C">
<PARAM NAME="cache_archive_ex" VALUE="applet.jar;preload, util.jar;preload;0.9.0.abc, tools.jar;0.9.8.7">
</OBJECT>
In the above example, a.jar is specified in archive, whereas b.jar, c.jar and d.jar are specified in cache_archive. The versions are also specified for b.jar, c.jar, and d.jar as 0.0.0.1, 0.0.A.B, and 0.A.B.C respectively. In cache_archive_ex, applet.jar is specified to be pre-loaded. util.jar is also specified to be pre-loaded but along with the version. Whereas for tools.jar, only version is specified.
Java Plug-In doesn't compare the versions if they are not specified for all the jar files specified in HTML parameter cache_archive. If cache_archive is used without cache_version, the jar files specified in cache_archive is treated no differently than the jar files specified in HTML parameter archive. Similar treatment goes to the jar files specified in cache_archive_ex without preload or version options.
Class files and resources will be searched in the following order from the jar files specified by the HTML parameters
1. cache_archive_ex
2. cache_archive
3. archive
dp
dnpa at 2007-7-15 23:59:48 >
having a hard time playing spite and malice on gamesville lycos.com
Can you show me a simple example manifest that would generate the right jar version number for one of the cache_archive_ex jars you listed with a version number?
Also, if you don't specify a manifest and you get the default manifest for a jar, does the jar have a "default" version number?
Basically I have a jar, didn't have a manifest/version number, want to now generate the jar with a manifest/version-number and change my HTML to use the OBJECT tag to enure the new version of the jar gets loaded. I tried a simple manifest with only
version-number: 2.0.0
and put that 2.0.0 version for the jar into cache_archive_ex
But that didn't seem to do the trick nd the old jar is still loaded ...
