Applet jar downloading

Hi,
As much as I understand, jars specified within the 'ARCHIVE' parameter of the APPLET tag are only downloaded when needed, i.e. a jar won't be dowloaded or at least not loaded into the classpath unless a class that's within it is being imported.
I conclude that by watching the java console messages which dislay whenever a jar is downloaded...
anyways, due to this behavior I occasionally run into flows that run really slowly because they import a class that's in a jar that wasn't yet downloaded... my question is whether there is anyway to tell the JVM to download in the background all jars specified in the ARCHIVE param ?
clearly I could add a swingworker that does that in the background but the problem is that this won't be automatic, i.e. whenever i'll add a new jar to the classpath, i'll need to write another import in the swing worker so that this jar will also be downloaded....
anyone ?
thanks,
Gil.

As much as I understand, jars specified within the 'ARCHIVE' parameter of the APPLET tag are only downloaded when needed, i.e. a jar won't be dowloaded or at least not loaded into the classpath unless a class that's within it is being imported.That doesn't even make sense. How can Java know what's in the JAR file without downloading it?
I suspect the truth is that Java downloads the JARS in the list in order whenever it needs a class it hasn't got yet, starting of course with the applet class itself and therefore the first JAR on the list.
anyways, due to this behavior I occasionally run into flows that run really slowly because they import a class that's in a jar that wasn't yet downloaded... my question is whether there is anyway to tell the JVM to download in the background all jars specified in the ARCHIVE param?Combine the JAR files. But that will slow down the initial loading of course. Lazy loading is an optimization, normally a good idea.

Similar Messages

Tomcat Session Tracking with Object Post and Repeated Applet Jar Download

Hi there,
I have an issue with session tracking in Tomcat (5.0.28) and the JRE repeatedly downloading the original Applet Jar.
Everything works fine (session tracking and HTTP GETs) until I post an Object from the Applet to a Servlet and the Servlet reads the Object.
After that happens the JRE downloads the Applet Jar about 20 times and continues to download it after further requests to the Servlet.
Not sure if the following is related but I'm parsing XML returned by the Servlet in the Applet and I get the following in the Tomcat logs:
127.0.0.1 - - [08/Feb/2005:08:43:12 +0000] "GET /[webapp_path]/servlet/META-INF/services/javax.xml.parsers.SAXParserFactory HTTP/1.1" 404 1142
If I turn off the session tracking in the Servlet it all works fine.
I'm using the standard HTTPSession tracking API.
Any help is much appreciated as this is a serious issue!
Ian

...furthermore...
I've now found I had disabled caching in the JRE.
If I enable it the immediately after a POST (not an Object) then the Applet is repeatedly downloaded and it appears more so than before.

Slow download of large applet jars - please help!

We have a large applet (7 meg plus several meg more
in 3rd party libraries) which take too long to download
under slow connections (e.g. wireless VPNs). We cannot
depend on browser/java-plugin cache to speed things up
because users clear caches often. Our market will not consider
an "installed application" as an alternative. There is now a political
effort where I work to throw out lots of excellent Java technology
because of this.
Here is what I need:
* Break our code into several smaller jars and initially
download just one small applet jar that logs a user into
our service.
* Treat all the rest of the jars as portions of a "plug-in", which
is downloaded after that, as needed, and installed on the client
machine outside of browser/plugin cache.
* The main small applet code would "install the plugin" as needed
and call into these installed jar files to do all the rest of it's work
* The jars that are part of this "plug-in" would have their own smart
update mechanism so only the portions changed in a new release
need to be downloaded - implemented apart from the Java plugin
cache.
Yes, the plugin concept is largely user perception, but in our market
it is unavoidable. If the first small piece loads and runs quicker, then
the installation of a "plugin" after that may be more tolerable. And the
downloaded components won't get lost by clearing caches.
If anyone has ideas on how to do this, please help. Otherwise a lot
of really good Java technology will go down the drain for largely
political reasons. I need a good technical solution for this.
Thanks,
/Mark

Another point: we need the first small jar file to download
and start running without the other jar files. The other jar files
need to then be downloaded on-demand and/or in the background
with good user feedback (e.g. progress bar) - giving the perception
to the user of "components of a plug-in" being installed. So we'd
need to invent some deferred-fetching stuff.
What users really don't like is waiting a long time for EVERYTHING
to download and nothing has actually started to run. It doesn't seem
like the Java plug-in alone will get us to that point.
/Mark

Multiple repeat downloads of applet jar file

We have an applet that is downloaded from a Weblogic server. The applet is packaged as a jar file. Some of the testers have been complaining that the applet is extremely slow to start up.
The applet start-up involves three phases. In a first phase, it fetches data from the server. This phase seems to execute in pretty much constant time. During the second and third phases, it constructs a UI using Swing objects. The UI includes some JPEG files, which are extracted from the applet's own jar file.
Testers report that the slow part of start-up is actually the UI setup. This should theoretically not be network-bound at all. But packet tracing reveals that during this phase, there's a large amount of network traffic going on. It turns out that there are multiple GET requests for the applet jar file being issued. Typically, 29 requests are issued in all; just for reference, the applet is required to extract 28 images from its jar file, so it looks as if the additional requests correspond to image requests.
One further detail: this does not occur where there is a fast connection to the server. In these cases, the applet is downloaded once. It looks as if the problem only occurs on slower network connections, and the speculation here is that the applet jar is somehow being downloaded only partially, so that requests for images somehow trigger a re-request of the jar file.
Has anyone seen anything similar and, more to the point, is there a fix or workaround?
Technical details: Internet Explorer 5.5 or 6.0, JRE version 1.4.2_01 Java HotSpot(TM) Client VM (on the client), WebLogic 8.1 (on the server)
Thanks in advance for any help.

Ok.
I have been trying hard and found the solution. One of the ablove posting says that it works under java 1.4.1 plug-in. That's infact absolutely true. It also says that how to run client using JRE 1.4.2 or higher. That can be solved two. This is definitely a bug with the 1.4.2 plug-in.
Follow this procedure that will solve the mystry.
----------------------start ---------------------------------
Problem
Download of applet is very slow
Why?
This was happening because of the repeated download of the applet jars by the applet plug in controller. It is quite clear that the Java 1.4.2 plug in controller has a bug that causes the plug in to download same jar files multiple times irrespective of Jar cache in the client side (configurable from client side using the Java plug in control panel) is enabled or disabled. Therefore, we have moved from 1.4.2 plug in to 1.4.1 (controlled from our client (JSP) code) that works fine.
What the client (applet client) should do?
You must do the following in the client side in order to avoid the long download time for applet when running from a browser. We have also found that the browser actually do not matter in slow applet downloads. It is only the plug in that does control the applet download.
Irrespective of what JVM you have already installed (or not yet installed) please do the following:
1. Download the JRE 1.4.2 from http://java.sun.com/products/archive/index.html
-At the time of its installation if it shows that the "JRE is already installed do you uninstall it?" Go ahead and uninstall the JRE 1.4.2. After the un-installation again install the JRE 1.4.2
-If it does not have the JRE 1.4.2 already installed, then you will see any warning window and you will be able to install the 1.4.2 JRE successfully.
2. Now, go to the same link and install JRE 1.4.1.
-If this JRE already installed, uninstall first like the step 1 above. then reinstall it.
3. Now, after successful installation of the JRE 1.4.1, open the Plug-In control panel.
-You will find the list of control panel(s) in the Start->Control Panel window. Use the control panel that shows the version number 1.4.1. If no version number shown then use the one that do not show any version number at its end.
4. Do the following on the Plug-In control panel.
-Verify if this is the 1.4.1 plug in control panel? Go to the "About" tab to see if it shows 1.4.1.
If it does not show the 1.4.1 (or 1.4.1_x) then plug in was not installed correctly. Reinstall the 1.4.1 JRE following the step in no-2
-Go to "Basic" tab and select "Show console" radio button.
-Go to "Advanced" tab and from the drop down select "JRE ...1.4.2" from the "Java Runtime Environment" drop down box.
-Go to "Browser" tab and select all that in the "Settings" box applicable for browsers.
-Go to "Cache" select "Enable Caching" if it is not selected currently. Select "Unlimited" from "Size" options.
Now hit "Apply" button at the bottom and close the control panel using the 'X'.
5. Restart your Windows machine.
6. You are ready to run the applet from any of the browser (IE, NS, etc.)
--------------------------end------------------------------

BigIP F5 : changing IP leads to cache invalidated and redownload of applet jars

Hello all,
In short, I'm trying to figure out how to have the java 7 plugin not considering the server IP to decide whether to use cached version of our applet's signed jars.
As suggested in the title, we use BigIP's F5 boxes to dispatch requests among actual servers, which are located in 2 different sites (disaster recovery purposes).
Each site has an F5 box ; and our DNS resolve the application's host name by alternating between 2 different IPs : one for site 1, the other for site 2.
Each time a user visits http://theapp.mycompany.com, the host is resolved as 9.9.9.1 or 9.9.9.2, more or less randomly.
This works very nicely as long as the applet is not concerned, or bandwith and latency is good enough to absorb 1.5Mb in a snap.
For remote subsidiaries (10.000km away from servers), downloading 1.5Mb takes 35s -- too much for the normal user to wait.
And the problem is : the plugin insists on looking up the server IP each time it starts up, and ignores cache entries that have been downloaded from a different IP.
Here is the use case :
- user connects to http://theapp.mycompany.com ; the browser get an IP, doesn't matter which ; user logs on, navigates in the app's html pages -- no problem
- user gets to the applet :
- the html page says
<applet id="myApplet">
    <param name="archive" value="a.jar,b.jar,c.jar,d.jar,e.jar"/>
    <param name="codebase_lookup" value="false"/>
    <param name="archive_1" value="a.jar, preload, version=7.5.7" />
    <param name="archive_2" value="b.jar, preload, version=7.5.7" />
    <param name="archive_3" value="c.jar, preload, version=7.5.7" />
    <param name="archive_4" value="d.jar, preload, version=7.5.7" />
    <param name="archive_5" value="e.jar, preload, version=7.5.7" />
    <param name="baseUrl" value="/"/>
    <param name="code" value="a/package/for/Applet.class"/>
    <param name="mayscript" value="mayscript"/>
    <param name="codebase" value="/applet/"/>
    <param name="name" value="MyApplet" />"
    <param name="locale" value="fr"/>
</applet>
     The archive_n parameters are here in an attempt to tell the plugin to not even ask for jars if its cache contains entries with same host/same name/same version.
     The version is assigned at build time at an application level ; it has nothing to do with the Implementation-Version attribute found in MANIFEST.MF files.
- Java and the plugin sarts up : let's assume this is the first time : cache is empty : all jars are downloaded ; as they are signed and the CA certificate chain was set in the browser config, and the java.policy is also configured to allow smooth exec, the applet runs smoothly -- after a long startup delay
- user leaves the applet, do some stuff in other applet-less pages for some minutes (the java/plugin processes are shut down after a minute or so)
- user reenters the page that contains the applet
- Java and the plugin start up again :
     - the cache has entries for each jar : host, name, version are all ok.
     - But : the jars are not seen as "prevalidated" ; heres' the applet log ( in French, translation provided after "//") :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.7
security: La vérification de révocation de la liste noire est activée     // Check of blacklist revocation is activated
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
..... same for the other jars ....
network: Created version ID: 7.5.7
network: Created version ID: 7.5.7
network: Entrée de cache trouvée [URL : http://theapp.mycompany.com/applet/a.jar, version : 7.5.7] prevalidated=false/0 //Cache entry found
cache: Adding MemoryCache entry: http://sandbox-mosaic.jcdecaux.com/applet/plannerApplet_7.5.7.jar
network: Created version ID: 7.5.7
     - The plugin then tries to lookup the host IP to check whether it matches that seen when creating the entry
     - 2 possibilities here :
               - the IP returned is the same : the plugin is happy, uses the cached jar, no question/download to/from the server, and the applet starts up quick and runs ok
               - the IP returned is not the same ; the plugin says :
network: Vérification de version pour a.jar. La version spécifiée est 7.5.7     //Checking version for a.jar. Specified version is 7.5.
security: blacklist: created: NEED_LOAD, lastModified: 1378474147992
security: blacklist: hasBeenModifiedSince 1380806409906 (we have 1378474147992)
security: La vérification de liste de bibliothèques sécurisées est activée     // Check of trusted libraries is activated
cache: CacheEntry IP mismatch: 9.9.9.1 != 9.9.9.2
          and then it downloads again the jar.
          Of course, all the jars are treated the same way.
          Note that the applet eventually runs normally ; the only problem is that the cache essentially doesn't work, causing terribly annoying 35s delays at applet startup.
Interestingly enough, examining the jdk 6 code shows that the "prevalidated=false" fragment (in bold/pink above) means that the method CacheEntry.isKnownToBeSigned() returns false.
I tried with a self-signed certificate which I added first in IE as "Trusted publisher" ; I also tried with a certificate signed by a CA that is known by IE -- no help.
So I really wonder : what does it take to have the plugin consider that each jar "isKnownToBeSigned" ?
Any thoughts ?
Note : we of course are considering packing jars, cleaning dead code, etc. to decrease applet size. But it doesn't help with the fact that the plugin considers the IP, which it shouldn't do in our case. And even with pack200 we're left with +350Kb of unnecessary downloads, not counting with future code to be developped ...
Thanks for any feedback
David
Browser is IE7.
Complete dump of system properties :
__applet_launched = 280874909499
__jvm_launched = 280874910680
acl.read = +
acl.read.default =
acl.write = +
acl.write.default =
awt.toolkit = sun.awt.windows.WToolkit
browser = sun.plugin
browser.vendor = Oracle
browser.version = 1.1
file.encoding = Cp1252
file.encoding.pkg = sun.io
file.separator = \
file.separator.applet = true
http.agent = Mozilla/4.0 (Windows Vista 6.0)
http.auth.serializeRequests = true
https.protocols = TLSv1,SSLv3
java.awt.graphicsenv = sun.awt.Win32GraphicsEnvironment
java.awt.printerjob = sun.awt.windows.WPrinterJob
java.class.path = C:\tools\Java\jre7\classes
java.class.version = 51.0
java.class.version.applet = true
java.endorsed.dirs = C:\tools\Java\jre7\lib\endorsed
java.ext.dirs = C:\tools\Java\jre7\lib\ext;C:\Windows\Sun\Java\lib\ext
java.home = C:\tools\Java\jre7
java.io.tmpdir = C:\Users\taille\AppData\Local\Temp\
java.library.path = C:\tools\Java\jre7\bin;C:\Windows\Sun\Java\bin;C:\Windows\system32;C:\Windows;C:\Program Files\Internet Explorer;;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;C:\oracle\ORA102\bin;C:\Perl\site\bin;C:\Perl\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;c:\Program Files\Common Files\Roxio Shared\DLLShared\;C:\Program Files\JavaSoft\JRE\1.3.1_06\bin;C:\ORACLE\Ora92\jre\1.3.1\bin;C:\ORACLE\Ora92\jre\1.1.8\bin;C:\tools\Groovy-1.7.5\bin;C:\tools\Graphviz2.28\bin;C:\tools\Git\cmd;C:\tools\tortoiseSVN\bin;C:\Program Files\Windows Imaging\;.
java.protocol.handler.pkgs = sun.plugin.net.protocol|com.sun.deploy.net.protocol
java.rmi.server.RMIClassLoaderSpi = sun.plugin2.applet.JNLP2RMIClassLoaderSpi
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.7.0_21-b11
java.specification.name = Java Platform API Specification
java.specification.vendor = Oracle Corporation
java.specification.version = 1.7
java.vendor = Oracle Corporation
java.vendor.applet = true
java.vendor.url = http://java.oracle.com/
java.vendor.url.applet = true
java.vendor.url.bug = http://bugreport.sun.com/bugreport/
java.version = 1.7.0_21
java.version.applet = true
java.vm.info = mixed mode, sharing
java.vm.name = Java HotSpot(TM) Client VM
java.vm.specification.name = Java Virtual Machine Specification
java.vm.specification.vendor = Oracle Corporation
java.vm.specification.version = 1.7
java.vm.vendor = Oracle Corporation
java.vm.version = 23.21-b01
javaplugin.nodotversion = 10212
javaplugin.version = 10.21.2.11
javaplugin.vm.options = -Ddeployment.trace.level=all -Duser.language=en
javawebstart.version = javaws-10.21.2.11
line.separator = \r\n
line.separator.applet = true
mrj.version.applet = true
os.arch = x86
os.arch.applet = true
os.name = Windows Vista
os.name.applet = true
os.version = 6.0
os.version.applet = true
package.restrict.access.com.sun.deploy = true
package.restrict.access.netscape = false
package.restrict.access.org.mozilla.jss = true
package.restrict.access.sun = true
package.restrict.definition.com.sun.deploy = true
package.restrict.definition.java = true
package.restrict.definition.netscape = true
package.restrict.definition.org.mozilla.jss = true
package.restrict.definition.sun = true
path.separator = ;
path.separator.applet = true
sun.arch.data.model = 32
sun.awt.enableExtraMouseButtons = true
sun.awt.warmup = true
sun.boot.class.path = C:\tools\Java\jre7\lib\resources.jar;C:\tools\Java\jre7\lib\rt.jar;C:\tools\Java\jre7\lib\sunrsasign.jar;C:\tools\Java\jre7\lib\jsse.jar;C:\tools\Java\jre7\lib\jce.jar;C:\tools\Java\jre7\lib\charsets.jar;C:\tools\Java\jre7\lib\jfr.jar;C:\tools\Java\jre7\classes;C:\tools\Java\jre7\lib\deploy.jar;C:\tools\Java\jre7\lib\javaws.jar;C:\tools\Java\jre7\lib\plugin.jar
sun.boot.library.path = C:\tools\Java\jre7\bin
sun.cpu.endian = little
sun.cpu.isalist = pentium_pro+mmx pentium_pro pentium+mmx pentium i486 i386 i86
sun.desktop = windows
sun.io.unicode.encoding = UnicodeLittle
sun.java.command = sun.plugin2.main.client.PluginMain write_pipe_name=jpi2_pid7004_pipe37,read_pipe_name=jpi2_pid7004_pipe36
sun.java.launcher = SUN_STANDARD
sun.jnu.encoding = Cp1252
sun.management.compiler = HotSpot Client Compiler
sun.net.client.defaultConnectTimeout = 120000
sun.net.http.errorstream.enableBuffering = true
sun.os.patch.level = Service Pack 2
trustProxy = true
user.country = FR
user.dir = C:\dtaille\TMA\perfs_br\newcert
user.home = C:\Users\taille
user.language = fr
user.name = taille
user.script =
user.timezone = Europe/Paris
user.variant =
Vider les propriétés de déploiement...
active.deployment.proxy.bypass.local = false
active.deployment.proxy.same = false
active.deployment.proxy.type = 3
deployment.baseline.url = https://javadl-esd-secure.oracle.com/update/baseline.version
deployment.blacklist.url = https://javadl-esd-secure.oracle.com/update/blacklist
deployment.blacklisted.certs.url = https://javadl-esd-secure.oracle.com/update/blacklisted.certs
deployment.browser.path = C:\Program Files\Mozilla Firefox\firefox.exe
deployment.browser.vm.iexplorer = true
deployment.browser.vm.mozilla = true
deployment.cache.enabled = true
deployment.cache.jarcompression = 0
deployment.cache.max.size = 726
deployment.capture.mime.types = false
deployment.console.startup.mode = SHOW
deployment.control.panel.log = false
deployment.expiration.decision.10.21.2 = later
deployment.expiration.decision.suppression.10.21.2 = true
deployment.expiration.decision.timestamp.10.21.2 = 9/6/2013 15:29:3
deployment.insecure.jres = PROMPT
deployment.javafx.mode.enabled = true
deployment.javapi.cache.update = false
deployment.javapi.lifecycle.exception = false
deployment.javapi.log.filename =
deployment.javapi.runtime.type = 0
deployment.javapi.stop.timeout = 200
deployment.javapi.trace.filename =
deployment.javaws.appicon.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\appIcon\appIcon.xml
deployment.javaws.associations = ASK_USER
deployment.javaws.cache.update = false
deployment.javaws.concurrentDownloads = 4
deployment.javaws.install = IF_HINT
deployment.javaws.installURL = http://java.sun.com/products/autodl/j2se
deployment.javaws.logFileName =
deployment.javaws.muffin.max = 256
deployment.javaws.shortcut = ASK_IF_HINTED
deployment.javaws.splash.index = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache\6.0\splash\splash.xml
deployment.javaws.traceFileName =
deployment.javaws.uninstall.shortcut = false
deployment.javaws.update.timeout = 1500
deployment.javaws.viewer.bounds = 1723,197,881,546
deployment.jpi.mode.new = true
deployment.log = false
deployment.macosx.check.update = true
deployment.max.output.file.size = 10
deployment.max.output.files = 5
deployment.mime.types.use.default = true
deployment.modified.timestamp = 1380804178316
deployment.proxy.bypass.local = false
deployment.proxy.override.hosts =
deployment.proxy.same = false
deployment.proxy.type = 3
deployment.security.SSLv2Hello = false
deployment.security.SSLv3 = true
deployment.security.TLSv1 = true
deployment.security.TLSv1.1 = false
deployment.security.TLSv1.2 = false
deployment.security.askgrantdialog.notinca = true
deployment.security.askgrantdialog.show = true
deployment.security.authenticator = true
deployment.security.blacklist.check = true
deployment.security.browser.keystore.use = true
deployment.security.clientauth.keystore.auto = true
deployment.security.disable = false
deployment.security.https.warning.show = false
deployment.security.jsse.hostmismatch.warning = true
deployment.security.level = HIGH
deployment.security.local.applets = PROMPT
deployment.security.mixcode = DISABLE
deployment.security.notinca.warning = true
deployment.security.password.cache = true
deployment.security.run.untrusted = PROMPT
deployment.security.sandbox.awtwarningwindow = true
deployment.security.sandbox.casigned = PROMPT
deployment.security.sandbox.jnlp.enhanced = true
deployment.security.sandbox.selfsigned = PROMPT
deployment.security.trusted.policy =
deployment.security.validation.crl = false
deployment.security.validation.ocsp = false
deployment.security.validation.ocsp.publisher = false
deployment.system.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\SystemCache
deployment.system.security.blacklist = C:\tools\Java\jre7\lib\security\blacklist
deployment.system.security.cacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.jssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.oldcacerts = C:\tools\Java\jre7\lib\security\cacerts
deployment.system.security.oldjssecacerts = C:\tools\Java\jre7\lib\security\jssecacerts
deployment.system.security.trusted.certs = C:\tools\Java\jre7\lib\security\trusted.certs
deployment.system.security.trusted.clientauthcerts = C:\tools\Java\jre7\lib\security\trusted.clientcerts
deployment.system.security.trusted.jssecerts = C:\tools\Java\jre7\lib\security\trusted.jssecerts
deployment.system.security.trusted.libraries = C:\tools\Java\jre7\lib\security\trusted.libraries
deployment.system.tray.icon = true
deployment.trace = true
deployment.update.mime.types = true
deployment.user.cachedir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\cache
deployment.user.extdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\ext
deployment.user.logdir = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\log
deployment.user.security.blacklist = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist
deployment.user.security.blacklist.dynamic = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklist.dynamic
deployment.user.security.blacklisted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\blacklisted.certs
deployment.user.security.policy = file:/C:/Users/taille/AppData/LocalLow/Sun/Java/Deployment/security/java.policy
deployment.user.security.sandbox.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\sandbox.certs
deployment.user.security.saved.credentials = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\auth.dat
deployment.user.security.trusted.cacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.cacerts
deployment.user.security.trusted.certs = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.certs
deployment.user.security.trusted.clientauthcerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.clientcerts
deployment.user.security.trusted.jssecacerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecacerts
deployment.user.security.trusted.jssecerts = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.jssecerts
deployment.user.security.trusted.libraries = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\security\trusted.libraries
deployment.user.tmp = C:\Users\taille\AppData\LocalLow\Sun\Java\Deployment\tmp
deployment.version = 7.21
deployment.webjava.enabled = true
java.quick.starter = false

This behavior was introduced by a security "fix" intended to prevent a DNS re-binding attack which permits unsigned applets to escape the applet sandbox. The "fix" was, imo, very poorly thought out. You think you have a problem with 1.5 megabits of applet jars, but I have 8 megabytes, hundreds of thousands of users, with lousy networks. So now I'm stuck with a colocation vendor. Imagine my chagrin when they changed *their* ISP and thus their IP addresses.
As far as I can see, signed applets are already permitted (if the user allows) to communicate outside the sandbox, so this "fix" should not have been applied to signed jars, only to unsigned ones. There are a couple of other techniques that Oracle might have used to prevent this attack, but they chose the simplest one, effectively preventing anyone from using the most common, inexpensive strategies for improving the availability of their web-based Java applications.

How to load an applet jar file?

Hello everyone,
I have an applet that uses my own jar file and approximately 6 third party jar files. I set up jar indexing (jar -i) which will download the jar files when they are needed. All seems to work well, but now I want to manually load the jar files which I cannot get working.
When the applet starts, about 1/2 of the jar files are downloaded (because they are needed at startup). I then want to load the additional jar files in the background, after the gui is initialized. I have tried this using the below thread which is executed from within the applet's start method:
// Try to load additional jar files in background by loading a class from each jar file.
Thread loadClass = new Thread() {
public void run() {
    System.out.println("Loading classes...");
    try {
      // Tried loading classes this way, doesn't work.
      getClass().getClassLoader().loadClass("pkg1.Class1");
      getClass().getClassLoader().loadClass("pkg2.Class2");
      getClass().getClassLoader().loadClass("pkg3.Class4");
      getClass().getClassLoader().loadClass("pkg4.Class4");
      /* Loading classes this way doesn't work either.
      Class.forName("pkg1.Class1");
      Class.forName("pkg2.Class2");
      Class.forName("pkg3.Class3");
      Class.forName("pkg4.Class4");
    catch(ClassNotFoundException e) {
      // First attempt to load a class (pkg1.Class1) throws exception.
      System.out.println("Can't find class: " + e.getMessage());
loadClass.start();As you can see from above I am trying to load a class from each of the jar files so that the jar files would load into memory/cache. Unfortunately, it cannot find the classes. These are the errors from the java console:
Loading classes...
Loading: pkg1.Class1
Connecting http://my.server.com/my_dir/pkg1/Class1.class with no proxy
Connecting http://my.server.com/my_dir/pkg1/Class1.class with cookie "JSESSIONID=some_big_long_char_list"
Can't find class: pkg1.Class1
So it appears the jar file is not being downloaded. When I take away the dynamic jar loading (removing the "jar -i" & adding them all to the applet archive list) the thread executes correctly. So I know the class names, etc, are correct. How does one load an applet jar file?
Any help/suggestions are appreciated.

The above error I posted was because I forgot to index the jar files. That is why it couldn't find the jar file. I thought I was getting farther along with my problem, but I apparently just forgot to index the jars. I am now getting the problem that I got yesterday...
The applet freezes/hangs when it hits the thread. The GUI never opens (even though I'm running this thread right after the gui shows). The java console quits responding and the applet just stays the grey screen. I also tried the invoke later that you suggested.
public void start() {
// ...initialize gui...
// Applet freezes and remains grey, also the java console freezes.
javax.swing.SwingUtilities.invokeLater(new Runnable() {
    public void run() {
      System.out.println("Loading classes...");
      try {
        // When I comment out the below forName calls, the thread will still run evidenced through the done print statement.
        Class.forName("pkg1.Class1");
     Class.forName("pkg2.Class2");
     Class.forName("pkg3.Class3");
     Class.forName("pkg4.Class4");
        System.out.println("...Done loading classes");
      catch(Exception e)     {
        System.out.println("Can't find class: " + e.getMessage());
}

Where is the Applet JAR file?

When an Applet (the JAR) is downloaded to the local PC, exactly where (the directory) we can locate the Applet JAR file? Is the file managed by the Internet browser?

This has got to be browser-specific.
You shouldn't write code that depends on this kind of information anyway.

Certificate inquiry for changes in applet jar

Hi everybody,
I have an applet that uses a certificate to allow saving of file to local disk. I downloaded the certificate and imported in the keystore and cacerts using keytool.
However, there are cases we need to change the applet. I updated the jar file with the revised version of applet.
My question is: Do I need to change the certificate and perform again the importing to keystore and cacerts to point the the revised applet so that I could save a file to local disk?
My concern is that what if many users have already performed the certificate importing, do they need to do again the procedure of importing certificate.
Your comments are very appreciated.
Thanks!
vamendoza

You should only need to re-sign the applet jar with the same certificate.

Applet Size - Download times

Hi
this might be completely stupid questeion - but is there a way of checking how long it takes an applet to download without building it.
'I know that my applet has 2550 lines and need to increase this by approx 10-fold to approx 24073. Does this mean that the applet will take 10 times longer to download?
Is this very large for this kind of thing? The new lines are a lookup table - could i do this differently?
Aparantly we want to avoid linking to a database - but will do if it is the bast way -
Is there anywhere i can read up on this?
Many thanks
BuffySlayer
http://www.buffyslay.co.uk

'I know that my applet has 2550 lines and need to
increase this by approx 10-fold to approx 24073. Does
this mean that the applet will take 10 times longer to
download?Depends on how you distribute it.
If you use a jar, then stuff gets compressed and it depends on your data's "repetiveness" how much this yields.
On the other hand, different people have different connection speeds and it is not easy to judge speed.
Depends on where your typicall users reside, and
how they are connected.
Regards,
Marc

Applet JAR constraints?

Is there a size limit for Applet JARs? And does this differ for different systems/browsers? Are JARs read only? Are there other constraints in regards to Applets and JARs? I wasn't able to find much information on distributing Applets and JAR size, so any links, search terms or recommendations would be greatly appreciated...

elricscript wrote:
Is there a size limit for Applet JARs? .. Probably, but it would be much larger than the single most important constraint for an applet, which is that it downloads quickly.
..And does this differ for different systems/browsers?.. I'd say it comes down to a combination of connection speed and patience.
.. Are JARs read only?.. Yes.
.. Are there other constraints in regards to Applets and JARs? ...Yes, any number of them. One that immediately springs to mind is the layout of the Jar.

Jar download not working over dial up

Hey,
Our webstart application works just fine while connected to the lan at work. The various jars required by the application are downloaded without any problems.
However, when I try to access the same application over dial up (I have tried netzero and aol), the jar download fails in a rather weird fashion.
On clicking on the link for the application, the main jar e.g. main-application.jar downloads just fine, but the next jar in line fails with the following message
Unable to load resource: https://server.com:443/application/lib/axis.jar
Exception
JNLPException[category: Download Error : Exception: java.net.SocketException: Unexpected end of file from server : LaunchDesc: null ]
     at com.sun.javaws.cache.DownloadProtocol.doDownload(Unknown Source)
     at com.sun.javaws.cache.DownloadProtocol.getResource(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadJarFiles(Unknown Source)
     at com.sun.javaws.LaunchDownload.downloadEagerorAll(Unknown Source)
     at com.sun.javaws.Launcher.downloadResources(Unknown Source)
     at com.sun.javaws.Launcher.handleApplicationDesc(Unknown Source)
     at com.sun.javaws.Launcher.handleLaunchFile(Unknown Source)
     at com.sun.javaws.Launcher.run(Unknown Source)
     at java.lang.Thread.run(Unknown Source)
Wrapped Exception
java.net.SocketException: Unexpected end of file from server
     at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)
     at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)
     at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
     at java.net.HttpURLConnection.getResponseCode(Unknown Source)
     at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source)
     at com.sun.javaws.net.BasicNetworkLayer.doRequest(Unknown Source)
     at com.sun.javaws.net.BasicNetworkLayer.doGetRequest(Unknown Source)
Now, when i click on the application launch again, it proceeds to download the next jar e.g axis.jar in this case without a problem, but it will fail on the next jar
snippet from my jnlp file
<jar href="application.jar"/>
<jar href="lib/axis.jar"/>
<jar href="lib/castor-0.9.5.2-xml.jar"/>
<jar href="lib/commons-beanutils-1.5.jar"/>
<jar href="lib/commons-collections-2.1.jar"/>
Note : All of this works fine when im not using dial up to connect.
Does anyone have any ideas ?
Any help is greatly appreciated

pboeykens,
It may definitely be something with my network and/or firewall configuration. I'm just not sure where to look yet.
I have tried modifying apache settings to no avail.
I've tried turning KeepAlives off, changing the keep alive timeout and the max number of keep alives allowed on apache, but none of these setting changes had any effect on the jar download.
If you have any suggestions for what I might look at as far as my firewall settings, then I can take that to my security department.
My next step is to try and enable the debug logging with webstart to maybe get a better idea of why it thinks that no jar is available.
Thanks

Cannot perform Bean lookup on signed Applet jar

Hi All,
I'm after developing an applet which runs from a number of jars on an Orion app server. Each one of these jars are signed and I can access the Applet okay. The problem is that I make remote reference to EJB's throughout the application. I cannot perform a Bean lookup on a signed jar. The only way it can be done is when the Client is granted all permissions. The client should pop up an option to grant permissions.

If u are signing all the jar file along with the applet it should work
It does work fine with me. my code given below
note that i carry the following jar files along with my applet jar.
orion.jar,ejb.jar,,jta.jar,jnet.jar,jsse.jar,jcert.jar,parser.jar
and have them in my archive attribute of my html code for the applet
also all these jars are signed
hope this helps
regards
raees
public void init()
     try
          Hashtable env = new Hashtable();
          env.put(Context.INITIAL_CONTEXT_FACTORY, "com.evermind.server.rmi.RMIInitialContextFactory");
          env.put(Context.PROVIDER_URL, "ormi://solomon:23791/helloApp");
          env.put("java.naming.security.principal", "admin");
          env.put("java.naming.security.credentials", "secret");
          Context ic = new InitialContext (env);
          HelloHome hello_home = (HelloHome)ic.lookup("HelloBean");
     Hello hello = hello_home.create ();
          System.out.println (hello.helloWorld ());
     }catch(Exception e)
          e.printStackTrace();

Question about Java Applet Jar file signing.

These questions pertain to Java 6 Standard Edition 1.6.0_22-b04 and later.
I have gone through the Oracle Java Tutorial for generate public and private key information
to sign a jar file, and how to sign the jar itself, all at
[http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html|http://java.sun.com/developer/onlineTraining/Programming/JDCBook/signed.html]
, and seek some clarification on the following related questions:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?
-using the policytool policy file generator, what do I need to add under "Principals"
(if anything) when dealing with a Java applet? Are Codebase and SignedBy simply author information?
-If I choose to use a java.security.Permission subclass object set up in equivalent fashion within the Applet,
which class within the Applet jar do I instantiate that object in? Does it need to be mentioned
in the applet's jar Manifest.MF file?
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?
-With this being the case, can the applet now escape
the sandbox, be it with or without the stipulated
policy permissions?

848439 wrote:
-In order to "escape" the java applet sandbox that exists around the client's
copy of the applet running in their web browser, ie.
(something forbidden by default), is verification of the signed applet enough, or is a policy file required
to stipulate these details?Just sign the applet, the policy file is not necessary.
-Is the "keystore database" a java language service/process which runs in
the Server's memory and is simply accessed and started by default
by the client verifier program (appletview/web browser)?No.
-The public key certificate file (*.cer) is put in the webserver directory holding
the Applet jar file (ie. Apache Tomcat, for example).No. For a signed Jar, all the information is contained inside the Jar.
-Presumably, the web browser detects the signed jar
and certificate file, and provides the browser pop up menu asking the user
about a new, non recognised certificate (initially).
Is this so?No. It is the JVM that determines when to pop the confirmation dialog.
-With this being the case, can the applet now escape
the sandbox, ..Assuming the end-user OK's the trust prompt, yes.
..be it with or without the stipulated
policy permissions?Huh?

Loading images inside applet JAR

Hi
This is my issue: I have an applet which contains images inside the applet JAR. I want to display these images in my applet, but apparently due to browser access restrictions, I'm not allowed.
My first code was like this:
//security restrictions on browsers do not allow getResource
ImageIO.read(MyClass.class.getResource("imgs/img.png"));
//getResourceAsStream should be allowed by browsers
ImageIO.read(MyClass.class.getResourceAsStream("imgs/img.png"));Both lines work when I execute the applet locally (command line / programming IDE), but when I deploy it to my web server, the resource "imgs/img.png" becomes a relative URL to my web application context (like /webcontext/MyClass/imgs/img.png). It works locally because the call to getResource returns a URL object with "file:" protocol, but I need it to look for my images bundled inside the JAR, not web hosted images.
I need to avoid making the applet look for these images as a web resource... how can I do it?
Thanks!

dev@java wrote:
warnerja wrote:
I'm not convinced the code you posted wouldn't work, but since this is an applet, you have access to the Applet class. Check out the Applet.getImage method in conjunction with Applet.getCodeBase.
[http://java.sun.com/javase/6/docs/api/java/applet/Applet.html]
getCodeBase returns my web context, like http://myhost.com/mycontext/ , so it is pretty much the same as above.
Thanks for your replyThat is the way to load resources though. Hence back to my earlier statement about not being convinced it would not work, with this addition: It should work, assuming you actually do have the resources properly located with the web app, whether they be in a jar, or loose files relative to where the web app is. My guess at this point is that they are not.

Java3D applet deployment -- download extension

Hi, I need to deploy an applet using Java3D package. Trying to avoid the installation hassle (on the client side), I want to put the three packages available on the server (j3dcore.jar, j3dutils.jar, vecmath.jar), and then add the class path of these jar files in the manifest of the applet jar file. It's not working. now I start to wonder if such an approach is feasible or not. Can anyone give me some suggestions? Thanks a lot. (By the way, I uploaded my files on geocities (the yahoo free webspace) -- guess this does not make a difference, right?

Sorry. But I was not quite sure which forum would be the most appropriate one.

Applet jar downloading

Similar Messages

Maybe you are looking for