java.util.zip.ZipException：使用jnlp启动Java Web Start应用程序时，不是GZIP格式的异常

Question

I am launching java web start app with jnlp. The jnlp is generated dynamically using jsp. I have set jnlp.packEnabled to true in jnlp file. All the jars are repacked, signed and packed with java's pack200. using below ant script.

    <echo message="Repacking jars" />
            <apply executable="pack200" parallel="false">
                <arg value="--repack" />
                <fileset dir="${build.dir}" includes="*.jar" />
            </apply>

            <echo message="Signing jars" />
            <signjar destdir="${build.dir}" keyPass="test" keyStore="${project.root}/testKeys" storePass="test" alias="t">
                <fileset dir="${build.dir}" includes="*.jar" />
            </signjar>

            <echo message="Pack Signed jars" />
            <apply executable="pack200" parallel="false" dest="${build.dir}">
                <arg value="--modification-time=latest"/>
                <arg value="--deflate-hint=true"/>
                <arg value="--segment-limit=-1"/>
                <fileset dir="${build.dir}" includes="*.jar" />
                <targetfile />
                <srcfile />
                <mapper type="glob" from="*" to="*.pack.gz" />
            </apply>


java.util.zip.ZipException: Not in GZIP format
    at java.util.zip.GZIPInputStream.readHeader(Unknown Source)
    at java.util.zip.GZIPInputStream.<init>(Unknown Source)
    at java.util.zip.GZIPInputStream.<init>(Unknown Source)
    at com.sun.deploy.net.HttpDownloadHelper.download(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToTempFile(Unknown Source)
    at com.sun.deploy.cache.Cache.downloadResourceToCache(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.actionDownload(Unknown Source)
    at com.sun.deploy.net.DownloadEngine.downloadResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.deploy.cache.ResourceProviderImpl.getResource(Unknown Source)
    at com.sun.javaws.LaunchDownload$DownloadTask.call(Unknown Source)
    at java.util.concurrent.FutureTask.run(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)

on web start application launch its giving aboveerror. Please suggest how to solve this error. And when i try to view *.pack.gz file with WINRAR, i could see only one file with .pack extension,i cant open it with WINRAR says it is a damaged file.

EDIT 1 :File is not damaged. I am able unpack it manually using unpack200 and run from command prompt without any issues. Exception is shown only when the file is downloaded from jnlp. I doubt the dynamic generation of jnlp from jsp is causing the issue. Below is my jsp code. Could you please suggest me a solution to get rid of this exception when unpacking from dynamically generated jnlp file .

<%@ page contentType="application/x-java-jnlp-file" language="java"%>
<%@page session="false" %>
<%
response.setContentType("application/x-java-jnlp-file");%>
<!-- JNLP File -->
<?xml version="1.0" encoding="utf-8"?>
<jnlp spec="1.0+">
<information>
<title>Service</title>
<vendor>Service</vendor> </information> 
<security> <all-permissions /> </security> 
<resources> 
<jfx:javafx-runtime version="2.2.4+"
    href="http://javadl.sun.com/webapps/download/GetFile/javafx-latest/windows-i586/javafx2.jnlp" />
</resources> 
<resources> 
<!-- Application Resources --> 
    <property name="jnlp.packEnabled" value="true"/>
    <j2se version="1.7+" /> 
    <jar href="Test.jar" main="true"/> 
</resources> 
<application-desc
    name="main" main-class="com.test.Main" width="300"
    height="300">
    <argument><%= request.getParameter("userId")%></argument>
    <argument><%= request.getParameter("userName")%></argument>
</application-desc> 
<update check="always" policy="always" />
</jnlp>

Answer 1

I suggest you try tool unpack200 (it's in the JDK) to see if your .pack.gz is correct. If not, it might be a hardware issue.