glassfish
  1. glassfish
  2. GLASSFISH-11889

Java SE 1.6.0_19 breaks Java Web Start launches of app clients

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: v3.0.1
    • Fix Version/s: v3.0.1
    • Component/s: standalone_client
    • Labels:
      None
    • Environment:

      Operating System: All
      Platform: All

    • Issuezilla Id:
      11,889

      Description

      Changes in how Java Web Start loads classes in signed vs. unsigned JARs in Java
      SE 1.6.0_19 has broken app client launches using Java Web Start. (The changes
      are described here:
      http://java.sun.com/javase/6/docs/technotes/guides/jweb/mixed_code.html)

      Users are prompted with a warning that they are about to start an app containing
      a mix of signed and unsigned content. Even if they agree to continue, Java Web
      Start now uses different class loaders for signed vs. unsigned content and that
      breaks the Java Web Start launch.

        Activity

        Hide
        Tim Quinn added a comment -

        I am looking into some possible ways of fixing this.

        Show
        Tim Quinn added a comment - I am looking into some possible ways of fixing this.
        Hide
        Tim Quinn added a comment -

        For 3.0.1, the fix I am looking at will be for the Java Web Start support code
        in GlassFish to sign all the GlassFish JARs. (In 3.0 only gf-client.jar was
        signed.) Because the user can override the default signing alias with one of
        his or her own choosing during deployment, GlassFish will maintain possibly
        multiple copies of the system JARs, each signed with a different alias.
        GlassFish will record the need for a signed set of system JARs during deployment
        but will not actually sign a given system JAR until it receives the first
        reference to a particular signed system JAR as part of a Java Web Start client
        launch.

        The Java Web Start support code in GlassFish will know whether signed JARs for a
        particular alias have already been prepared and will not duplicate the work.

        There will be a performance penalty for having to do this, but by signing all
        the JARs Java Web Start will no longer warn the user that the app contains both
        signed and unsigned code and will load all the classes using the same class
        loader (which is necessary for the app client container and the client to work
        correctly as written).

        Show
        Tim Quinn added a comment - For 3.0.1, the fix I am looking at will be for the Java Web Start support code in GlassFish to sign all the GlassFish JARs. (In 3.0 only gf-client.jar was signed.) Because the user can override the default signing alias with one of his or her own choosing during deployment, GlassFish will maintain possibly multiple copies of the system JARs, each signed with a different alias. GlassFish will record the need for a signed set of system JARs during deployment but will not actually sign a given system JAR until it receives the first reference to a particular signed system JAR as part of a Java Web Start client launch. The Java Web Start support code in GlassFish will know whether signed JARs for a particular alias have already been prepared and will not duplicate the work. There will be a performance penalty for having to do this, but by signing all the JARs Java Web Start will no longer warn the user that the app contains both signed and unsigned code and will load all the classes using the same class loader (which is necessary for the app client container and the client to work correctly as written).
        Hide
        Tim Quinn added a comment -

        Fixed in 3.0.1 via the commit below (and in 3.1 in the commit described in a
        later update to this issue).

        Note that this fix will cause GlassFish to create signed copies of the GlassFish
        JARs which are used during Java Web Start launches. These signed JARs are
        created when GlassFish first receives a Java Web Start request for them. This
        means that the first user who launches a client using Java Web Start after a new
        GlassFish installation might see a longer-than-usual delay while GlassFish
        creates the signed copies of the JARs. But once any Java Web Start launch
        occurs, the signed copies of the JARs will be used for any Java Web Start launch
        of any application from any user.

        By default, the copies will be signed using the domain's self-signed certificate
        with alias s1as. If the user specified the optional jar-signing-alias property
        while deploying an app, then GlassFish will create separate copies of the
        required GlassFish JARs using that alias. Again, the same copy will be shared
        across all apps deployed with that jar-signing-alias and across all users
        launching those apps.

        Because the JARs downloaded are signed, Java Web Start on the client will take
        some additional time to verify these JARs before using them, as happens whenever
        a signed JAR opened. Note that this verification will occur each time a user
        launches an app, even if the locally cached copies of the GlassFish system JARs
        are used.

        Author: tjquinn
        Date: 2010-05-20 15:00:10+0000
        New Revision: 37116

        Modified:

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/AppClientDeployerHelper.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/NestedAppClientDeployerHelper.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/StandaloneAppClientDeployerHelper.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java

        branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java

        branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp

        branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp

        Show
        Tim Quinn added a comment - Fixed in 3.0.1 via the commit below (and in 3.1 in the commit described in a later update to this issue). Note that this fix will cause GlassFish to create signed copies of the GlassFish JARs which are used during Java Web Start launches. These signed JARs are created when GlassFish first receives a Java Web Start request for them. This means that the first user who launches a client using Java Web Start after a new GlassFish installation might see a longer-than-usual delay while GlassFish creates the signed copies of the JARs. But once any Java Web Start launch occurs, the signed copies of the JARs will be used for any Java Web Start launch of any application from any user. By default, the copies will be signed using the domain's self-signed certificate with alias s1as. If the user specified the optional jar-signing-alias property while deploying an app, then GlassFish will create separate copies of the required GlassFish JARs using that alias. Again, the same copy will be shared across all apps deployed with that jar-signing-alias and across all users launching those apps. Because the JARs downloaded are signed, Java Web Start on the client will take some additional time to verify these JARs before using them, as happens whenever a signed JAR opened. Note that this verification will occur each time a user launches an app, even if the locally cached copies of the GlassFish system JARs are used. Author: tjquinn Date: 2010-05-20 15:00:10+0000 New Revision: 37116 Modified: branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/AppClientDeployerHelper.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/NestedAppClientDeployerHelper.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/StandaloneAppClientDeployerHelper.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java branches/3.0.1/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp branches/3.0.1/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp
        Hide
        Tim Quinn added a comment -

        Fixed in 3.1.

        Author: tjquinn
        Date: 2010-05-20 15:14:01+0000
        New Revision: 37118

        Modified:

        trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java

        trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java

        trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java

        trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java

        trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java

        trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp

        trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp

        Show
        Tim Quinn added a comment - Fixed in 3.1. Author: tjquinn Date: 2010-05-20 15:14:01+0000 New Revision: 37118 Modified: trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/AppClientHTTPAdapter.java trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JWSAdapterManager.java trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/JavaWebStartInfo.java trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/NamingConventions.java trunk/v3/appclient/server/core/src/main/java/org/glassfish/appclient/server/core/jws/servedcontent/TokenHelper.java trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/appclientMainDocumentTemplate.jnlp trunk/v3/appclient/server/core/src/main/resources/org/glassfish/appclient/server/core/jws/templates/systemJarsDocumentTemplate.jnlp

          People

          • Assignee:
            Tim Quinn
            Reporter:
            Tim Quinn
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: