1 2 Previous Next 16 Replies Latest reply on Jun 15, 2009 12:34 PM by 843802

    Upgrade to 1.6.0_14 causing Webstart launched application to fail

    843802
      Hi, I am looking for a little help with changes made to Webstart and JNLP with update 14 for 1.6. I have an application that is packaged within a war and distributed to webserver to be launched with webstart. It has been working for 3 years without change (various versions of Java from 1.5 - 1.6.0_13) until just recently...

      Stack Trace received when trying to run the app:

      java.lang.SecurityException: class "com.cu.ajent.logger.AbstractAjentLogger"'s signer information does not match signer information of other classes in the same package
      at java.lang.ClassLoader.checkCerts(Unknown Source)
      at java.lang.ClassLoader.preDefineClass(Unknown Source)
      at java.lang.ClassLoader.defineClass(Unknown Source)
      at java.security.SecureClassLoader.defineClass(Unknown Source)
      at java.net.URLClassLoader.defineClass(Unknown Source)
      at java.net.URLClassLoader.access$000(Unknown Source)
      at java.net.URLClassLoader$1.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(Unknown Source)
      at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClassInternal(Unknown Source)
      at java.lang.ClassLoader.defineClass1(Native Method)
      at java.lang.ClassLoader.defineClass(Unknown Source)
      at java.security.SecureClassLoader.defineClass(Unknown Source)
      at java.net.URLClassLoader.defineClass(Unknown Source)
      at java.net.URLClassLoader.access$000(Unknown Source)
      at java.net.URLClassLoader$1.run(Unknown Source)
      at java.security.AccessController.doPrivileged(Native Method)
      at java.net.URLClassLoader.findClass(Unknown Source)
      at com.sun.jnlp.JNLPClassLoader.findClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClass(Unknown Source)
      at java.lang.ClassLoader.loadClassInternal(Unknown Source)
      at com.cu.ajent.client.gui.core.MainWindow.main(MainWindow.java:287)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
      at java.lang.reflect.Method.invoke(Unknown Source)
      at com.sun.javaws.Launcher.executeApplication(Unknown Source)
      at com.sun.javaws.Launcher.executeMainClass(Unknown Source)
      at com.sun.javaws.Launcher.doLaunchApp(Unknown Source)
      at com.sun.javaws.Launcher.run(Unknown Source)
      at java.lang.Thread.run(Unknown Source)

      The funny thing is, this particular class only exists in one jar file with that package name and it is signed. I am wondering if this is a red herring error or if I am just completely missing something.

      JNLP File that does not work with update 14 ONLY (all other versions of 5 and 6 work):
      Notes: All jar files that are pulled through this descriptor AND the 2 extension JNLP files are from the same "signed" directory and are all signed by the same certificate at build time

      <jnlp spec="1.0+" codebase="http://jeffl:8001/Ajility/" href="http://jeffl:8001/Ajility/Ajility.jnlp">
      <information>
      <title>Ajility Client</title>
      <vendor>Columbia Ultimate</vendor>
      <homepage href="http://jeffl:8001/Ajility/index.html"/>
      <description>Ajility Client Installation with Java Web Start</description>
      <description kind="short">Ajility Client</description>
      <icon href="http://jeffl:8001/Ajility/cu/images/Ajility_logo.jpg" kind="default"/>
      </information>
      <security>
      <all-permissions/>
      </security>
      <update check="always" policy="always"/>
      <resources>
      <java version="1.6"/>
      <property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>
      <property name="java.naming.provider.url" value="t3://jeffl:8001"/>
      <property name="java.security.auth.login.config" value="http://jeffl:8001/Ajility/cu/properties/jaas_client.conf"/>
      <property name="appserver.connector.class" value="com.cu.ajility.appserver.weblogic.WebLogicConnector"/>
      <jar href="http://jeffl:8001/Ajility/cu/lib/signed/AjilityGUI.jar" download="eager" main="false"/>
      <extension href="http://jeffl:8001/Ajility/JNLP/signed_client_libs.jnlp" name="Ajility_lib"/>
      <extension href="http://jeffl:8001/Ajility/JNLP/signed_wls_libs.jnlp" name="wls_lib"/>
      <nativelib href="http://jeffl:8001/Ajility/cu/lib/swt-win32-dll.jar" download="eager" main="false"/>
      </resources>
      <application-desc/>
      </jnlp>

      Here is the version of the JNLP file that works ONLY with update 14 (fails on all other versions of java 5 and 6)
      Notes: The ONLY jar files that are actually signed are the 2 that are referenced in this main JNLP file. None of the extension jars are signed.

      <jnlp spec="1.0+" codebase="http://jeffl:8001/Ajility/" href="http://jeffl:8001/Ajility/Ajility.jnlp">
      <information>
      <title>Ajility Client</title>
      <vendor>Columbia Ultimate</vendor>
      <homepage href="http://jeffl:8001/Ajility/index.html"/>
      <description>Ajility Client Installation with Java Web Start</description>
      <description kind="short">Ajility Client</description>
      <icon href="http://jeffl:8001/Ajility/cu/images/Ajility_logo.jpg" kind="default"/>
      </information>
      <security>
      <all-permissions/>
      </security>
      <update check="always" policy="always"/>
      <resources>
      <java version="1.6"/>
      <property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>
      <property name="java.naming.provider.url" value="t3://jeffl:8001"/>
      <property name="java.security.auth.login.config" value="http://jeffl:8001/Ajility/cu/properties/jaas_client.conf"/>
      <property name="appserver.connector.class" value="com.cu.ajility.appserver.weblogic.WebLogicConnector"/>
      <jar href="http://jeffl:8001/Ajility/cu/lib/AjilityGUI.jar" download="eager" main="false"/>
      <extension href="http://jeffl:8001/Ajility/JNLP/client_libs.jnlp" name="Ajility_lib"/>
      <extension href="http://jeffl:8001/Ajility/JNLP/wls_libs.jnlp" name="wls_lib"/>
      <nativelib href="http://jeffl:8001/Ajility/cu/lib/swt-win32-dll.jar" download="eager" main="false"/>
      </resources>
      <application-desc/>
      </jnlp>

      Can anyone give me an idea or a place to start?
        • 1. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
          793415
          Welcome to the Sunf forums.
          jefflawson wrote:
          ...
          Can anyone give me an idea or a place to start?
          You might start by checking the launch using JaNeLA. Some of those launch files appeared invalid to my eye, but JaNeLA will tell you for sure.
          • 2. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
            843802
            Maybe it's something about signing or about pack200 if you're using it and you're 'normalizing' file by compressing and decompressing them before signature.
            Did you tried using 6u14's jarsigner (and, eventually, pack200 and unpack200), maybe some backward-compatible change happened that makes something go wrong signing with previous updates and executing with 6u14.
            • 3. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
              843802
              Thank you for the suggestions. The launch files are valid, I think the error has something to do with security and signing. Possibly a behavioral change with u14. After doing some testing over the weekend I believe I discovered a few interesting differences with web start.

              The "extension" JNLP jar files no longer are required to be signed in order to get <all-permissions> during execution. For example, if I run the application under u14 with only the main jar signed, log4j and other extension jars have no trouble accessing the file system. If I run the same app under u13, log4j cannot access the file system and I can get trace and log information showing me the exception. This was why I signed "everything", even the jar files previously.

              I am beginning to wonder if there is a particular jar file that is causing me the problems. Maybe something that is signed by a different certificate previous to me signing it. Perhaps u14 is enforcing something I did not expect? Does anyone have more developer detail on the changes that were made to JNLP with u14?
              • 4. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                793415
                >
                Thank you for the suggestions. The launch files are valid, ..>
                *No, they are not valid!* What on Earth made you say that, without checking them against a DTD or XSD?

                Not only are they invalid, but they are also illogical. Fix the validation errors and post new versions, and I might expand on that, but if you are intent on keeping up this silliness about how that rubbish you put at the top of the thread is 'valid' - I won't bother continuing.
                • 5. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                  843802
                  How am I supposed to take that comment? It is invalid because some tool you gave me a link to says it is not? Perhaps you should read the spec as what your tool is referring to as invalid is most completely valid for the content of a JNLP file. Sounds like you are getting a little bit personal. Maybe constructive help would be better to use as I came to this forum for that, not someone to tell I am "illogical" as well. Why don't you tell me why I am so illogical? Plus, if the JNLP launch file is so invalid, why did it work for 2 years?

                  "The resources element has six different possible subelements: jar, nativelib, j2se, property, package, and extension. The package and extension elements are not discussed in this developer's guide. See the Java Network Launching Protocol & API Specification (JSR-56) version 6.0 for details."

                  Your tool says there is only 3 {java, j2se, and jar}...

                  "The property element defines a system property that will be available through the System.getProperty and System.setProperties methods. It has two required attributes: name and value. For example:
                  <property name="key" value="overwritten"/>"

                  Again, your tool does not think these are valid? Huh? Maybe I am not getting this but I have been working with webstart for a while and have a little experience using the JNLP file syntax, loading resources, and passing -D arguments through <properties> elements under <resources>.

                  Would you like to politely comment and help me or could someone else take a look?
                  • 6. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                    793415
                    The errors you got from the reporting tool, you misinterpreted. Those errors were because you had elements out of order. Once I had placed the elements in the correct order, the validation tool then informed me that the 'main' attribute was not valid for a nativelib element. This is the closest version of that JNLP file that is valid according to the spec.
                    <jnlp spec="1.0+" codebase="http://jeffl:8001/Ajility/" href="http://jeffl:8001/Ajility/Ajility.jnlp">
                    <information>
                    <title>Ajility Client</title>
                    <vendor>Columbia Ultimate</vendor>
                    <homepage href="http://jeffl:8001/Ajility/index.html"/>
                    <description>Ajility Client Installation with Java Web Start</description>
                    <description kind="short">Ajility Client</description>
                    <icon href="http://jeffl:8001/Ajility/cu/images/Ajility_logo.jpg" kind="default"/>
                    </information>
                    <security>
                    <all-permissions/>
                    </security>
                    <update check="always" policy="always"/>
                    <resources>
                    <java version="1.6"/>
                    <jar href="http://jeffl:8001/Ajility/cu/lib/signed/AjilityGUI.jar" download="eager" main="false"/>
                    <nativelib href="http://jeffl:8001/Ajility/cu/lib/swt-win32-dll.jar" download="eager"/>
                    <extension href="http://jeffl:8001/Ajility/JNLP/signed_client_libs.jnlp" name="Ajility_lib"/>
                    <extension href="http://jeffl:8001/Ajility/JNLP/signed_wls_libs.jnlp" name="wls_lib"/>
                    <property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>
                    <property name="java.naming.provider.url" value="t3://jeffl:8001"/>
                    <property name="java.security.auth.login.config" value="http://jeffl:8001/Ajility/cu/properties/jaas_client.conf"/>
                    <property name="appserver.connector.class" value="com.cu.ajility.appserver.weblogic.WebLogicConnector"/>
                    </resources>
                    <application-desc/>
                    </jnlp>
                    So once you climb down off your high horse and correct all the JNLP files, come back and we'll talk bout the remaining illogical feature. That is, if you are interested in solving this launch problem, rather than pouting about your hurt feelings.
                    • 7. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                      843802
                      Some time ago I heard multiple signatures (in order to re-sign already signed jar) would have been supported in new JREs, maybe 6u14 does this. I don't know, you may try to give a look at release notes.
                      Once again: did all tools you used to 'manipulate' jars came from 6u14? Did you try using previous JDKs?

                      Bye.

                      PS: order matters, can't tell why, but if you give a look throughout the forum, you'll se JaNeLa has helped many (and Andrew even more). You could just tell out you don't think this is your case, but coming back saying jnlp is valid sounded a bit presumptuous. Just try to understand there are people in the forum giving out their time and knowledge for free and getting rewarded with insults as well as dukes. We can snap sometime ;-)
                      • 8. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                        843802
                        You are right. The JNLP file contents, as is posted, do not validate against the JNLP-6.0.10.dtd. In fact, according to XML Spy, the ONLY problem my posted file contained was that the nativelib element cannot have an attribute main. That is not actually in my original file, it is appended automatically after loading with webstart as I do not use the download or main attributes in the original. I posted exactly what I found in the webstart application viewer. Other than the nativelib attribute issue (which is done by javaws) the file is completely valid...including all of the elements in which you say are out of order. Would you like me to send you a link to the spec's dtd or can you not climb down off of your soap box long enough to be helpful. You seem to have got caught up in some other world where you missed the 2 important facts: 1. The files work 2. Something changed between 1.6.0_13 and 1.6.0_14.

                        Now, I would like to get to how I actually solved this problem. I am not saying it is the perfect way to do it, but I worked for me with any of the java 6 releases.

                        1. I stopped signing every jar file I was packaging in the war application. Since there are some eclipse and swt libraries being downloaded, they were already signed and I just made sure they were loaded through the extension jnlp files.

                        2. I moved all of my application jar files (same package names) into the main JNLP and made sure they remain getting signed along with the jar file with the main class.

                        After doing this, I had no problem launching in u14, but still had problems with u13 or lower. But now I was getting a pretty good trace log and noticed that the log4j jar file was attempting to access a resource url for the log4j configuration and could not:

                        log4j:ERROR Could not parse url [jar:http://jeffl:8001/Ajility/cu/lib/AjilityGUI.jar!/log4j.xml].
                        and
                        java.security.AccessControlException: access denied (java.io.FilePermission C:\Documents and Settings\Ajility_Service\Ajility\log\AjilityGUILog.txt write)

                        3. Another change that I made, had to do with the java.policy file. In the past, we packaged a java.policy file that gave certain permissions to the jvm. I know this is not secure and not the right way to do it, but it was a workaround for the error above. This appears to be corrected in u14, but to be backward compatible with older vms, I still need to download the new java policy that gives log4j permission.

                        Here is the correct JNLP file for those interested.

                        <jnlp codebase="$$context" spec="1.0+" href="$$context/Ajility.jnlp">

                        <!--Provide application information-->
                        <information>

                        <title>Ajility Client</title>
                        <vendor>Columbia Ultimate</vendor>
                        <homepage href="index.html"/>
                        <description>Ajility Client Installation with Java Web Start</description>
                        <description kind="short">Ajility Client</description>
                        <icon href="$$context/cu/images/Ajility_logo.jpg"/>

                        </information>

                        <!--Set security for sandbox-->
                        <security>
                        <all-permissions/>
                        </security>

                        <update check="always"/>

                        <resources>
                        <!--Set properties that will be used as JVM -D arguments-->
                             <j2se version="1.6"/>
                             <property name="java.naming.factory.initial" value="weblogic.jndi.WLInitialContextFactory"/>
                        <property name="java.naming.provider.url" value="t3://jeffl:8001"/>
                             <property name="java.security.auth.login.config" value="$$context/cu/properties/jaas_client.conf"/>
                             <property name="java.security.policy" value="$$context/cu/properties/java.policy"/>
                             <property name="appserver.connector.class" value="com.cu.ajility.appserver.weblogic.WebLogicConnector"/>

                        <!--Resource jar with MAIN-->
                        <jar href="cu/lib/AjilityGUI.jar"/>
                        <jar href="cu/lib/AjilityCommon.jar"/>
                        <jar href="cu/lib/AjilityConnectors.jar"/>

                        <!--Extension jnlp files that contain required resources to be used-->
                        <extension href="$$context/JNLP/client_libs.jnlp" name="Ajility_lib"/>
                        <extension href="$$context/JNLP/wls_libs.jnlp" name="wls_lib"/>

                        </resources>

                        <!--OS specific resources or native libs (dlls or so files) that exist in jars-->
                        <resources os="Windows">
                        <nativelib href="cu/lib/swt-win32-dll.jar"/>
                        </resources>

                        <application-desc/>

                        </jnlp>

                        So, in summary, I think my problem was 3 fold and all were potentially changes or fixes to the behavior of webstart and jnlp. Could someone verify that for me or give me a little more insight. I realize that (according to some people) I was just doing it wrong before...but it did work and I am trying to find the best solution to fix it.

                        1. Do not sign jars that are already signed by a different certificate
                        2. Load signed resources of the same package names in the same jnlp file
                        3. If you have a resource which needs access to the file system prior to update 14, you need to specify a java.policy file as a new resource for the javaws app and give proper permissions (again, I know this probably not the right way to do it, but the behavior here is certainly different between java versions)

                        Thanks.
                        • 9. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                          793415
                          The webstart console output? (Slaps forehead) I did not even think to ask if that was your original, 'unadultered' JNLP file.

                          The one thing I noted about it, that seemed especially odd, was this line..
                          <jar href="http://jeffl:8001/Ajility/cu/lib/signed/AjilityGUI.jar" download="eager" main="false"/>
                          1) This is an application description.
                          2) An application-desc requires a Jar with a main()
                          3) There is only one Jar listed as a resource in this application-desc, so therefore..
                          4) Why is it flagged as main="false"?

                          I do not know if that flag was added by you or the plug-in, but it does not make sense to me. If the main() is not in AjilityGUI.jar, where is it?
                          • 10. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                            843802
                            The main is in the AjilityGUI.jar. Spec says that if you don't identify it with an attribute it will use the main of the first jar file referenced. Not sure why it puts main="false", other than the fact that it is the default unless otherwise specified. I did not put the raw file in the post because I use a serlvet to dynamically set certain values ($$context) and I did not want to any more confusion to a problem with a lot of gray area.

                            What is really interesting is that the altered version from jws adds the main="false" to the nativelib element, which is invalid according to the dtd.

                            So I guess, my biggest problem (ability to support all jre6 versions) is resolved, but I will looking for a way to pull the java.policy out of the properties so I don't have to override the jvm security policy for log4j.
                            • 11. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                              843802
                              Hello,

                              I am also having a problem with this upgrade to 1.6.0_14. Webstart was working find with us throughout java 6 but this upgrade broke it. Here is the JNLP. All of the jars are signed by our own certificate, but the error is saying that one of our jars is not signed. I am 100% positive that the jar is signed. In the release notes i saw them say that if we set an "insecure system property" that it throw this error? Here is our jnlp please help!

                              <?xml version="1.0" encoding="utf-8"?>
                              <jnlp spec="1.0+"
                              codebase="http://$$app.codebase$$:8080/smartwerks/webstart"
                              href="smartwerks.jnlp">
                              <information>
                                   <title>$$app.title$$</title>
                                   <vendor>Tyler Retail Systems</vendor>
                                   <description>$$app.title$$</description>
                                   <homepage href="http://$$app.codebase$$:8080/smartwerks"/>
                                   <description kind="short">$$app.title$$</description>
                                   <icon href="images/smartwerks_logo_icon.jpg" width="64" height="64" kind="short"/>
                                   <icon href="images/smartwerks_logo.jpg" kind="splash" />
                                   <shortcut online="true">
                                        <desktop/>           
                                        <menu submenu="Tyler Retail Systems"/>
                                   </shortcut>
                                   <update check="always" policy="always" />
                              </information>

                              <security>
                                   <all-permissions/>
                              </security>

                              <resources>
                                        
                                        <jar href="Smartwerks-client.jar" main="true"/>
                                        <jar href="lib/Smartwerks-common.jar"/>
                                        
                                        <jar href="lib/FastInfoset-1.2.3.jar" />          
                                        <jar href="lib/XmlSchema-1.4.5.jar" />               
                                        <jar href="lib/aopalliance-1.0.jar" />
                                        <jar href="lib/bsf-2.4.0.jar" />
                                        <jar href="lib/bsh-1.3.0.jar" />
                                        <jar href="lib/commons-codec-1.3.jar" />
                                        <jar href="lib/commons-collections-3.1.jar" />
                                        <jar href="lib/commons-lang-2.4.jar" />
                                        <jar href="lib/commons-logging-1.1.1.jar" />
                                        <jar href="lib/cxf-2.2.1.jar" />
                                        <jar href="lib/cxf-manifest.jar" />
                                        <jar href="lib/forms-1.0.5.jar" />
                                        <jar href="lib/geronimo-activation_1.1_spec-1.0.2.jar" />
                                        <jar href="lib/geronimo-annotation_1.0_spec-1.1.1.jar" />
                                        <jar href="lib/geronimo-javamail_1.4_spec-1.2.jar" />
                                        <jar href="lib/hsqldb.jar" />          
                                        <jar href="lib/imaging.jar" />
                                        <jar href="lib/informa.jar" />          
                                        <jar href="lib/jaxb-api-2.1.jar" />
                                        <jar href="lib/jaxb-impl-2.1.9.jar" />
                                        <jar href="lib/jcalendar.jar" />
                                        
                                        
                                        <!-- jasper reporting -->          
                                        <jar href="lib/iText-2.1.4.jar" />
                                        <jar href="lib/jasperreports-3.5.0.jar" />
                                        <jar href="lib/poi-3.2-FINAL-20081019.jar" />
                                        <jar href="lib/poi-contrib-3.2-FINAL-20081019.jar" />
                                        <jar href="lib/poi-scratchpad-3.2-FINAL-20081019.jar" />
                                        <jar href="lib/jxl.jar" />          
                                                  
                                        <!-- java desktop -->
                                        <jar href="lib/jdic.jar" />
                                        <jar href="lib/jdic_stub.jar" />
                                        <nativelib href="lib/jdic_dll.jar" />
                                                  
                                        
                                        <!-- JIDE -->
                                        <jar href="lib/jide-action.jar" />
                                        <jar href="lib/jide-beaninfo.jar" />
                                        <jar href="lib/jide-common.jar" />
                                        <jar href="lib/jide-components.jar" />
                                        <jar href="lib/jide-dashboard.jar" />          
                                        <jar href="lib/jide-dialogs.jar" />
                                        <jar href="lib/jide-dock.jar" />
                                        <jar href="lib/jide-editor.jar" />
                                        <jar href="lib/jide-grids.jar" />
                                        <jar href="lib/jide-pivot.jar" />
                                        <jar href="lib/jide-rss.jar" />
                                        <jar href="lib/jide-shortcut.jar" />
                                        
                                        <!-- java help -->
                                        <jar href="lib/jsearch.jar" />
                                        <jar href="lib/jh.jar" />
                                        <jar href="lib/jhall.jar" />
                                        <jar href="lib/jhbasic.jar" />
                                        
                                        <!-- jgoodies -->
                                        <jar href="lib/looks-1.2.2.jar" />
                                        
                                        <!-- misc utils -->
                                        <jar href="lib/log4j-1.2.11.jar" />          
                                        <jar href="lib/mail.jar" />
                                             
                                        <jar href="lib/neethi-2.0.4.jar" />
                                        <jar href="lib/pixie-0.99.0.jar" />
                                                  
                                        <jar href="lib/syndiag2.jar" />
                                        <jar href="lib/velocity-1.5.jar" />          
                                        <jar href="lib/wsdl4j-1.6.2.jar" />
                                        <jar href="lib/wss4j-1.5.6.jar" />
                                        <jar href="lib/wstx-asl-3.2.6.jar" />
                                        <jar href="lib/xercesImpl.jar" />
                                        <jar href="lib/xml-apis-1.3.02.jar" />
                                        <jar href="lib/xml-resolver-1.2.jar" />
                                                                      
                                        <j2se version="1.6.0_5+" href="http://java.sun.com/products/autodl/j2se" java-vm-args="-ea" initial-heap-size="128m" max-heap-size="512m" />
                                                  
                              </resources>

                              <application-desc main-class="com.tylernet.smartwerks.client.main.Main"/>
                              </jnlp>
                              • 12. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                                843802
                                At a glance:
                                1) You're using javahelp: did you get the unsigned version and signed it? Cause the one distributed through Sun's site is already signed (as seen here ).
                                2) You don't have properties in your jnlp, so you can't have insecure ones, for sure.
                                3) You could have used some extensions (or parts at least), just to keep some order instead of blocking out stuff using comments. No need for it, just a bit more read-friendly.
                                4) Given the previous posts, couldn't you pleeeeeease validate the jnlp before posting? It just looks like a match (aka flame-starter). No offence.

                                Bye.
                                • 13. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                                  843802
                                  Given the prior posts, validating the JNLP file had NOTHING to do with the problem (in fact, the insistence that it be validated caused more problems than not). The simple fact here is that this JNLP file did work with prior versions of the JRE.

                                  Could you give the exact error or stack trace produced? I found that you cannot re-sign a jar that has already been signed with u14.
                                  • 14. Re: Upgrade to 1.6.0_14 causing Webstart launched application to fail
                                    843802
                                    Move any jars that were are signed by a different certificate into a separate jnlp file and add an extension href in the main jnlp.

                                    For example:

                                    <extension href="$$context/help_libs.jnlp" name="JavaHelp"/>

                                    Where $$context is resolved as through the servlet.
                                    1 2 Previous Next