This week's book giveaway is in the Other Open Source APIs forum. We're giving away four copies of Storm Applied and have Sean Allen, Peter Pathirana & Matthew Jankowski on-line! See this thread for details.
I'm maintaining an applet. All jars are signed. Aside from the applet jar itself, it requires 9 additional jars totalling >30MB (I didn't originate this design).
I know Swing, but next to nothing about applet deployment.
Security is web-based (SiteMinder)
The serving page's <OBJECT> entry looks like this:
(It does not use the cache_archive_ex tag, which I have seen mentioned in forums and articles, but do not completely understand)
I have the 1.5 plugin. I open the cache and clear it, but keep it open to watch the arrival of the jars. I also have FileMon running to watch the access of the files in the cache.
So, hit the applet page, and in the console you see several blocks of output, where it's retrieving each jar specified in the <OBJECT> tag of the serving page. Each block passes by, stalling as the file downloads. When the log continues, the file has appeared in the cache. All good. I understand that much.
The cache viewer now shows all 10 jars, and the URL for each one is the SERVER url of the jar, as specified in the HTML page that served the applet.
So now, the app starts to load. By this point I've seen thousands of hits on the locally cached jars, meaning the applet is using them as it initializes.
Now, in the console, what I see for each jar again is a block of code. Different from the first blocks, where the console was saying
over and over... now it's saying:
And with each such block there is a pause. That pause is congruent with the size of the jar. essd9 (Actuate's eSpreadsheet jar) is 19MB... the pause is 2 minutes. xerces.... maybe 5 seconds, and so on.
If you set up an applet-serving page to force the download of a bunch of jars... and caching is turned on in the plugin....and FileMon shows that the application is using those jars...
Then why does the console appear to be downloading the jars on the server again.... why is it hitting those originating URLs... and not just referencing them for a second... long enough that it FEELS like a download (even though the cached versions don't change)?
ANY help at all would be very much appreciated.
Thanks in advance. digital_nomad
(UD: added linebreaks to preserve layout) [ January 25, 2008: Message edited by: Ulf Dittmer ]
I'm no expert on using the OBJECT tag or jar caching, but you might want to look through the Java Plugin Developer's Guide to see if anything jumps out at you. It's got a section on applet caching.
Joined: Jan 24, 2008
I found the answer, at least in this case, so I thought I would post it for future seekers.
In the object tag (on the applet-serving HTML page), you specify auxiliary jars needed by the applet, and their associated versions, just like shown in my first post.
The java plugin then forces the download of those jars if you do not have them. They are recorded with whatever version number you gave them in the object tag, and whatever "originating URL" you gave them.
Thereafter, when the applet is started, it first gets the applet jar (if necessary, and then as the applet starts up, and references classes in your auxiliary jars, it looks at the jars that contain those classes. For each one (only once) it will open a URLConnection to the originating URL for that jar, and read the last mod timestamp on the file on the server. if the last mod indicates the cache has the latest version, it should terminate the connection.
What I was seeing was that the plugin would download the file anyway... all 9 of them in my case.
Why? Check this out. In you're application code, when writing an applet, you will likely have one or more spots where you yourself open URLConnections to the server. And more often than not, the initialization code for the URLConnection looks like:
however there is another call that people will often habitually make in their code, perhaps not knowing of it's effect:
When you do this, ANYWHERE in your code, it sets a static variable on URLConnection that affects all other URLconnections' defaults. Since the plugin is effectively in the same JVM as your application, if you make that call, from that point forward the default is to not use the cache, even if the plugin itself is set to "use cache".
I looked in my [inherited] source, and sure enough... 7-8 different places, seeming out of habit rather than any particular purpose, there were calls to .
I removed them, and just like that, the plugin functions as expected. Jars are only downloaded when needed, and the app startup time has been greatly reduced.
Hope this helps someone.
Joined: Mar 22, 2005
Thanks for reporting back, Pete. That's good to know (and not at all obvious).