We are using Java web start for deploying our application.
All JAR files are signed and there is no problem with deploying and using the application with all Java versions (including 8u73).
With JRE 8u74, application was deployed OK (all JAR files downloaded and application started correctly).
When trying to extract a file from a JAR file we are getting the following message:
Failed to validate certificate. The application will not be executed.
java.security.cert.CertificateException: Could not verify signing in resource: https://www.example.com:443/app/myFile.jar
at com.sun.deploy.security.TrustDecider.ensureAllJarEntriesSigned(Unknown Source)
at com.sun.deploy.security.TrustDecider.getValidationState(Unknown Source)
at com.sun.deploy.security.TrustDecider.validateChain(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGrantedInt(Unknown Source)
at com.sun.deploy.security.TrustDecider.isAllPermissionGranted(Unknown Source)
at com.sun.deploy.security.DeployURLClassLoader.getResourcePermission(Unknown Source)
at com.sun.deploy.security.DeployURLClassLoader.getResourceAsStream(Unknown Source)
at com.til.manager.B.A.A(Unknown Source)
at com.til.manager.B.A.D(Unknown Source)
at com.til.manager.B.A.B(Unknown Source)
at com.til.manager.app.H$6.run(Unknown Source)
Caused by: com.sun.deploy.net.JARSigningException: Could not verify signing in resource: https://www.example.com:443/app/myFile.jar
This happens for several files.
This error message is shown when our application tries to extract files from the JAR files to the local computer.
Further investigating we found that on 8u74, for the following code:
ClassLoader classLoader = this.getClass().getClassLoader();
classLoader.getResource("").getPath();
the second line returns NULL.
On all previous Java version this was working correctly.
Could this be connected to the error message?
Any idea why this is happening or how to fix this problem?
The API documentation for ClassLoader.getResource(String) claims that it will return null "if the resource could not be found or the invoker doesn't have adequate privileges to get the resource". Moreover, I tested the code you listed using the OpenJDK 1.7.0_95 as well as the Oracle JDK 1.8.0_72, and with both of them it did not return null on my system but rather it returned the execution directory (e.g. /home/errantlinguist/Eclipse%20Workspaces/Default/ClassLoaderTest8/bin/).
These two pieces of evidence suggest that the null reference you're getting is a symptom of the problem rather than the cause: CertificateException "indicates one of a variety of certificate problems", and is moreover a subclass of GeneralSecurityException-- note the words privileges and security.
Are you absolutely sure that your manifest for myFile.jar is correct?-- If so, what exact JVM are you runnng?-- If your manifest is correct, it is possible this problem may be related to a reported bug in OpenJDK 8u72. Unfortunately, without further information about your deployment, it isn't possible to know for sure.
I had the same problem, but the Jar referred to by my JNLP had only DLLs in it, no Java code. Upon reading hundreds of similar threads relating to this problem it became apparent that I might need to add a Jar to the JNLP that actually included Java code. So, my original JNLP included 4 Jars with DLLs as follows:
<resources os="Windows" arch="x86">
<nativelib href="lib/jogl/jogl-all-natives-windows-i586.jar"/>
</resources>
<resources os="Windows" arch="amd64">
<nativelib href="lib/jogl/jogl-all-natives-windows-amd64.jar"/>
</resources>
<resources os="Windows" arch="x86">
<nativelib href="lib/jogl/gluegen-rt-natives-windows-i586.jar"/>
</resources>
<resources os="Windows" arch="amd64">
<nativelib href="lib/jogl/gluegen-rt-natives-windows-amd64.jar"/>
</resources>
This failed with the Java.security.cert.CertificateException: Could not verify signing in resource: ...
Then, when I added a signed Jar that has Java code in it as follows, the problem went away:
<resources>
<jar href="lib/hdf/jhdf.jar"/>
</resources>
Related
I wrote a simple program in java using eclipse. The program requires disk access (read and write) and some internet access. I want to create a web start application out of it, so I downloaded netbeans. I imported the project and ran it with netbeans. Everything worked. After that I right clicked the project, went to web start => I selected local Execution, selected an icon and signed it with my own created key. (I didn't select "Allow offline").
After that I hit f11 and the project build. I went to the project folder and opened the dist folder and dragged everything to my desktop (C:\Users\teddy\Desktop\host). I double clicke dlaunch.jnla and then I got the error: Unable to laucn hthe application
I clicked details. The error looks like this:
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: file:/C:/Users/teddy/workspace/facebooker/dist/facebooker.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
I also used JaNeLA to chech the jnla file, this is the output:
JaNeLA Report - version 11.05.17
Report for file:/C:/Users/teddy/Desktop/host/launch.jnlp
Content type application/xml does not equal expected type of application/x-java-jnlp-file
cvc-complex-type.2.4.a: Invalid content was found starting with element 'security'. One of '{resources, application-desc, applet-desc, component-desc, installer-desc}' is expected.
cvc-complex-type.2.4.a: Invalid content was found starting with element 'security'. One of '{resources, application-desc, applet-desc, component-desc, installer-desc}' is expected.
XML encoding not known, but declared as UTF-8
Codebase + href 'file:/C:/Users/teddy/workspace/facebooker/dist/launch.jnlp' is not equal to actual location of 'file:/C:/Users/teddy/Desktop/host/launch.jnlp'.
Optimize this application for off-line use by adding the <offline-allowed /> flag.
Downloads can be optimized by specifying a resource size for 'facebooker.jar'.
The resource download at facebooker.jar can be optimized by removing the (default) value of download='eager'.
Lazy downloads might not work as expected for facebooker.jar unless the download 'part' is specified.
Downloads can be optimized by specifying a resource size for 'lib/restfb-1.6.14.jar'.
The resource download at lib/restfb-1.6.14.jar can be optimized by removing the (default) value of download='eager'.
The resource download at lib/restfb-1.6.14.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the lib/restfb-1.6.14.jar resource.
Lazy downloads might not work as expected for lib/restfb-1.6.14.jar unless the download 'part' is specified.
Downloads can be optimized by specifying a resource size for '007.jpg'.
Icon loading & use can be optimized by specifying the width and height for 007.jpg
Report for file:/C:/Users/teddy/workspace/facebooker/dist/jnlpcomponent1.jnlp
Content type application/xml does not equal expected type of application/x-java-jnlp-file
XML encoding not known, but declared as UTF-8
Optimize this application for off-line use by adding the <offline-allowed /> flag.
Downloads can be optimized by specifying a resource size for 'lib/forms-1.3.0.jar'.
The resource download at lib/forms-1.3.0.jar can be optimized by removing the (default) value of download='eager'.
The resource download at lib/forms-1.3.0.jar can be optimized by removing the (default) value of main='false'.
It might be possible to optimize the start-up of the app. by specifying download='lazy' for the lib/forms-1.3.0.jar resource.
Lazy downloads might not work as expected for lib/forms-1.3.0.jar unless the download 'part' is specified.
#
Does anyone knows what's going on here?
The JNLP file looks like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<jnlp codebase="file:/C:/Users/teddy/workspace/facebooker/dist/" href="launch.jnlp" spec="1.0+">
<information>
<title>facebooker</title>
<vendor>teddy</vendor>
<homepage href=""/>
<description>facebooker</description>
<description kind="short">facebooker</description>
<icon href="007.jpg" kind="default"/>
</information>
<update check="always"/>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.7+"/>
<jar href="facebooker.jar" main="true"/>
<jar href="lib/restfb-1.6.14.jar"/>
<extension href="jnlpcomponent1.jnlp"/>
</resources>
<application-desc main-class="">
</application-desc>
</jnlp>
i have the following JNLP file:
<jnlp spec="1.0+" codebase="http://****:****" href="tcm2012.jnlp">
<information>
<title>TCM 2012</title>
<vendor>Drift og Performance, *** Servicecenter</vendor>
<homepage href="http://******"/>
<description/>
</information>
<security>
<all-permissions/>
</security>
<resources>
<j2se version="1.6+"/>
<jar href="tcm2012.jar"/>
</resources>
<application-desc main-class="com.****.kundeservice.TCMApplication"/>
</jnlp>
Now when i try to run in from the web i get the following error:
Found unsigned entry in resource
With the following exepction
com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: http://*****:****/tcm2012.jar
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.security.JNLPSignedResourcesHelper.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareResources(Unknown Source)
at com.sun.javaws.Launcher.prepareAllResources(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main.access$000(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Does anyone know how to fix this problem?
This worked for me:
Go the Control Panel/Java.
Then click on “Settings” button and activate the option “Keep temporary files on my computer.”
It’s weird, but it worked!
The problem can also occur with older Java Versions if you sign with a newer Java versions.
Sign with 1.8u74 and older works with all versions
Sign with 1.8u101 and newer works with 1.7u80 and newer but not with older versions on the client.
There seems a incompatible change in the sign algorithm.
I had a similar problem with my applications.
I' ve a java swing application deployed with javaws:
when I run the application using JRE 1.6 I get the exception
when I run the application using JRE 1.7 and JRE 1.8 it works
I checked all the jar, MANIFEST.MF etc. and all was fine.
Finally I discovered that I've used a new TSA endpoint to sign my jars.
when I use this TSA http://tsa.starfieldtech.com the application run fine with JRE6,8
when I use this TSA http://services.globaltrustfinder.com/adss/tsa the application runs only with JRE8
From this resource http://docs.oracle.com/javase/7/docs/technotes/tools/windows/jarsigner.html I read
To generate the time stamp, jarsigner communicates with the TSA with the Time-Stamp Protocol (TSP) defined in RFC 3161. When successful, the time stamp token returned by the TSA is stored with the signature in the signature block file.
Someone can give more insight about this problem? In particular I don't want to be forced to use a particular TSA.
Why there are this differences between TSA?
Thanks
I my case the applet really had unsigned entry in META-INF folder. )
One way to fix that would be to re-sign it.
But in java 8 self-signed applets were demoted to almost the same level as unsigned ones. And the applet didn't required any additional privileges.
So it was sufficient to just un-sign it and add to trusted sites list.
I had the same problem when compiling on my linux maschine (with JDK 6 U45).
But I got this error only when I also tried to start the signed application with Java 6 U45.
When I try to start the application with a newer Java-Version (e.g Java 8) it was OK all the time, with no error message.
When I used a windows maschine to compile the project (also with 6 Update 45), it strangely works also when I use Java 6 U45 to start.
Just my 2 cents....
Cheers!
And many thanks to all who will take time for reading.
I'm struggling to make a webstart Swing 1.4.2_12 application to launch with java webstart 1.6.0_29.
Here is the scenario :
All traffic is done over HTTPS
User clics a link on a web page to launch the application : servlet
generated jnlp file
Java webstart client (1.6.0_29) starts and loads the application in
a breath
Because the j2se version is set to 1.4.2_12 in jnlp descriptor java
webstart 1.4.2_12 is used to launch the application (loaded by
1.6.0_29)
Java webstart 1.4.2_12 fails on startup claiming that it cannot find some ghost "javaws2" file
The following message is reported:
CouldNotLoadArgumentException[ Could not load specified file/URL : C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2]
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Full stacktrace is:
java.io.FileNotFoundException: C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2 (File not found)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(Unknown Source)
at java.io.FileInputStream.<init>(Unknown Source)
at com.sun.javaws.jnl.LaunchDescFactory.buildDescriptor(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The same error occurs when HTTPS is disabled.
Both the following HTTP headers are sent to the client by JNLP servlet :
Cache-Control : empty
Pragma : empty
These headers are necessary to prevent IE to disable caching in HTTPS mode wich prevents java webstart to find the loaded jnlp file (because it is not cached).
Mime-type is set to : application/x-java-jnlp-file
What I do not understand is why java 1.4.2_12 cannot find the jnlp file loaded by JWS 1.6.0_29 ?
Thanks for reading.
#Andrew : Thank you for your interest.
Here comes my conclusions on that issue.
In a nutshell : Always set the href attribute in the the jnlp tag !
<jnlp spec="1.0+" codebase="htt://myhost/codebase" href="mustSetThisAbsolutelyForJWS-1.4.2_12.jnlp">
...
</jnlp>
Multiple HTTP debug sessions have shown that :
Scenario 1: href attribute is left empty and JNLP files are associated with JWS 1.6 on the client
User clicks a jnlp link, JNLP file is downloaded and cached by
browser.
JWS 1.6.0_29 starts up then read the downloaded JNLP file.
JWS 1.6.0_29 downloads all JAR files and then switches to JWS 1.4.2_12.
JWS 1.4.2_12 starts up and then obviously read the JNLP file in its turn.
JWS 1.4.2_12 tries to retrieve the JNLP file pointed by the href
attribute.
Since href is empty, JWS reports "Could not load specified file/URL
: C:\DOCUME~1\BENOIT~1.VAT\LOCALS~1\Temp\javaws2". (As a side note, ghost javaws2 is sometimes named javaws10 or similar)
Please note : When using JWS 1.4 or 1.5 with this scenario, the
application WILL start. The issue only appears when JWS 1.6 is used
to run a 1.4.2_12 application. JWS 1.5 and 1.6 do not fail when no
href attribute is set. Instead they simply use the JNLP as is, check the
JAR updates and then launch the application.
Scenario 2: href attribute is set with a proper value and JNLP files are associated with JWS 1.6 on the client
User clicks a jnlp link, JNLP file is downloaded and cached by
browser.
JWS 1.6.0_29 starts up then read the downloaded JNLP file.
JWS 1.6.0_29 downloads all JAR files and then switches to JWS 1.4.2_12.
JWS 1.4.2_12 starts up and then obviously read the JNLP file in its turn.
JWS 1.4.2_12 tries to retrieve the JNLP file pointed by the href
attribute.
JWS 1.4.2_12 downloads the JNLP pointed by the href attribute.
JWS 1.4.2_12 downloads all JNLP JAR files referenced in the freshly downloaded JNLP file.
JWS 1.4.2_12 launches the application correctly.
It's been a major pain in the neck for me and took me days to figures this out. Hope this will help someone one day.
Sorry for this question but I'm a newbie to Java. I tried searching for similar problems, and I did find some answers, but none worked in my case, so here it goes:
I'm trying to load a java applet on a web page. The applet is supposed to be loaded from a .jar file (UCFApplet.jar), but I cannot get it to load no matter what.
Here's the html for the applet:
<applet id="UCFApplet" height="200" width="200"
code="com.fujitsu.test.applet.UCFApplet"
archive="UCFApplet.jar">
</applet>
The jar file is on the server, on the same folder than the html file that is trying to load it. Inside the jar file there's a UCFApplet.class file on com/fujitsu/test/applet folder.
The error I'm getting on the Java console is the following:
Java Plug-in 1.6.0_29
Using JRE version 1.6.0_29-b11 Java HotSpot(TM) Client VM
User home directory = C:\Users\PTMAIAJ
----------------------------------------------------
c: clear console window
f: finalize objects on finalization queue
g: garbage collect
h: display this help message
l: dump classloader list
m: print memory usage
o: trigger logging
q: hide console
r: reload policy configuration
s: dump system and deployment properties
t: dump thread list
v: dump thread stack
x: clear classloader cache
0-5: set trace level to <n>
----------------------------------------------------
load: class com.fujitsu.test.applet.UCFApplet not found.
java.lang.ClassNotFoundException: com.fujitsu.test.applet.UCFApplet
at sun.plugin2.applet.Applet2ClassLoader.findClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass0(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.plugin2.applet.Plugin2ClassLoader.loadCode(Unknown Source)
at sun.plugin2.applet.Plugin2Manager.createApplet(Unknown Source)
at sun.plugin2.applet.Plugin2Manager$AppletExecutionRunnable.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Exception: java.lang.ClassNotFoundException: com.fujitsu.test.applet.UCFApplet
As you can see, I'm using jre 1.6.0_29 build 11, which, from what I get on the Oracle page, is the latest build. This happens on all browsers (IE 9, FF, Chrome).
I suspect it may have something to do with not being able to access the .jar file because if I change the html code to a dummy name such as archive="thisFileDoesNotExist.jar" it gives me the same error. But I don't really know what to put there in order to make it work.
Any idea about what I can be doing wrong ?
Thank you and best regards,
Joao Maia
Your descriptor seems to be correct, so try the following.
First check that browser can download the jar. Type the direct URL to jar file into your browser. For example if your html can be accessed by typing
http://localhost/myapp/mypage.html
type
http://localhost/myapp/UCFApplet.jar
If you can download the jar and it is identical to your jar continue.
Check the jar itself. Type in command line
jar vft UCFApplet.jar
and see output. You should be able to find your class:
/com/fujitsu/test/applet/UCFApplet.class
BTW do you know that applet tag is deprecated and is not supported by Opera and Chrome? To support all browsers you should use tag object
Try turning on tracing in the java control panel. It will then produce a log file in the following path that may help:
%USERPROFILE%\AppData\LocalLow\sun\java\Deployment\log
In my case I had an error which only appeared when I turned on tracing, and which presented as simply a "ClassNotFoundException":
java.util.zip.ZipException: duplicate entry: META-INF/LICENSE.txt
The applet loader was rejecting the jar because the zip file had a duplicate file entry. Strangely appletviewer.exe was able to load and run this jar fine.
For those of you running behind a corporate proxy. According Oracle ClassNotFoundException is "a common error that is seen if the proxy settings are not correct".
See: How do I configure proxy settings for Java?
I have a Java application, built with eclipse, that uses QTJambi. Running the application from the command line works perfectly.
java -d32 -XstartOnFirstThread -jar MyApplication.jar someArg
However, trying to deploy the application with WebStart is proving difficult. I've done a whole lot of reading and it seems many people have issues getting this to work on Mac OS X. The issue seems to be that the native libraries aren't being correctly loaded. The stack trace is provided below.
CWindow's _nativeHide encountered error: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at com.sun.javaws.Launcher.invokeMainMethod(Launcher.java:1819)
Caused by: java.lang.ExceptionInInitializerError
at com.trolltech.qt.QtJambiObject.(QtJambiObject.java:60)
at com.engage.agentdesktop.Application.main(Application.java:25)
... 5 more
Caused by: java.lang.RuntimeException: Loading library failed, progress so far:
No 'qtjambi-deployment.xml' found in classpath, loading libraries via 'java.library.path'
Loading library: 'libQtCore.4.dylib'...
- using 'java.library.path'
at com.trolltech.qt.internal.NativeLibraryManager.loadNativeLibrary(NativeLibraryManager.java:431)
at com.trolltech.qt.internal.NativeLibraryManager.loadQtLibrary(NativeLibraryManager.java:355)
at com.trolltech.qt.Utilities.loadQtLibrary(Utilities.java:140)
at com.trolltech.qt.Utilities.loadQtLibrary(Utilities.java:136)
at com.trolltech.qt.QtJambi_LibraryInitializer.(QtJambi_LibraryInitializer.java:56)
... 7 more
Caused by: java.lang.RuntimeException: Library 'libQtCore.4.dylib' was not found in 'java.library.path'=/Users/smeatonj/Desktop/Engage Agent Desktop.app/Contents/Resources/Java:/System/Library/PrivateFrameworks/JavaApplicationLauncher.framework/Resources:.:/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java
at com.trolltech.qt.internal.NativeLibraryManager.loadLibrary_helper(NativeLibraryManager.java:486)
at com.trolltech.qt.internal.NativeLibraryManager.loadNativeLibrary(NativeLibraryManager.java:426)
... 11 more
This is an extract of the webstart.jnlp file:
`[resources`]
`[j2se version="1.5+"/`]
`[jar href="${MEDIA_URL}application/webstart/MyApplication.jar" /`]
....
`[jar href="${MEDIA_URL}application/webstart/MyApplication_lib/qtjambi-4.5.2_01.jar" /`]
`[resources os="Mac OS X"`]
`[j2se version="1.5+" java-vm-args="-d32 -XstartOnFirstThread"/`]
`[jar href="${MEDIA_URL}application/webstart/MyApplication_lib/qtjambi-macosx-gcc-4.5.2_01.jar" /`]
`[/resources`]
The error tells me that qtjambi-deployment.xml is not found in the classpath. I've opened up qtjambi-macosx-gcc-4.5.2_01.jar and there is definitely the qtjambi-deployment.xml file there.
The resources os="Max OS X" node is definitely being loaded by the JNLP, because I was receiving different errors before that required me to put -d32 into the vm args. Does anyone know what the hell could be causing this error?
Edit:
The application runs fine when webstarting to Windows.
For those that come after, this is the information that we discovered about deploying Jambi via webstart to Mac OS X.
qtjambi-macosx-gcc-4.5.2_01 can not be found when installing/launching from webstart. If this library is on your path, webstart is able to find it and use it, and will launch correctly. Further, there are some JNLP properties that need to be set.
<resources os="Mac OS X">
<!-- Currently Unsupported-->
<property name="com.trolltech.launcher.webstart" value="true" />
<property name="com.trolltech.verbose-loading" value="true" />
<j2se version="1.5+" java-vm-args="-d32 -XstartOnFirstThread"/>
<jar href="/path/to/qtjambi-macosx-gcc-4.5.2_01.jar" />
</resources>
The property com.trolltech.launcher.webstart is required to inform the Jambi libraries that we are starting via webstart, and to configure itself in such a way that allows webstart to work. Unfortunately, it's broken for mac os x at this point in time.
The QTJambi Community Port to 4.6 solves the above problem, but introduces a new problem.
http://qt.gitorious.org/qt-jambi/community-port-to-4_6
http://sourceforge.net/apps/trac/qtjambi/ticket/37
I've investigated this bug as well, and it requires changing one line of code to get working, namely, changing the class loader to play nice with webstart (more secure class loader). I haven't attempted yet, due to the build system being quite off putting and not having the time to investigate properly.
So, if you're having troubles deploying QT Jambi applications with webstart on Mac OSX, you now know why. If anyone gets around to changing 4.6, please post here and update this information. Alternatively, if I get around to changing it, I'll post here also.
Useful references:
http://doc.qt.nokia.com/qtjambi-4.3.5_01/com/trolltech/qt/qtjambi-systemproperties.html