JDK-4720897 : Jar Diff'ing does not work if jars are packaged in a war file.
  • Type: Bug
  • Component: deploy
  • Sub-Component: webstart
  • Affected Version: 1.2.0
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-07-25
  • Updated: 2003-04-12
  • Resolved: 2002-10-15
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
1.4.2 mantisFixed
Description

Name: nt126004			Date: 07/25/2002


FULL PRODUCT VERSION :
java version "1.4.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0_01-b03)
Java HotSpot(TM) Client VM (build 1.4.0_01-b03, mixed mode)

also:

java version "1.4.1-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.1-beta-b14)
Java HotSpot(TM) Client VM (build 1.4.1-beta-b14, mixed mode)

On the client, java web start 1.0.1 and 1.2 beta -> differences outlined below

Also: the version of tomcat that comes with the java web services developer
pack 1.0

FULL OPERATING SYSTEM VERSION : Microsoft Windows 2000
[Version 5.00.2195]


A DESCRIPTION OF THE PROBLEM :
If the application is packaged in a war file, jar
differencing does not work, as the class
com.sun.javaws.servlet.JarDiffHandler uses
ServletContext.getRealPath to find the two jars to
differ. However, as stated in the docs for that method,
it will return null if the context refers to a war file.

In web start 1.0.1 this null file name will lead to a null
pointer exception. In web start 1.2, this null file name
means that no attempt is made to create the jar difference
file and the full version is returned instead. This means
that there is no way to package a web start application
into a war file and take advantage of jar differencing.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Package jars for web start application into war file
2. Run the application on a client
3. Update one or more of the jars, changing the version
number
4. repackage into a new war file and deploy to the server
5. launch the application again from the client. At this
point, a .jardiff file should be created, instead I get the
following output when the logLevel attribute is set to
DEBUG in the web.xml file:

JnlpDownloadServlet(3): Resource returned: /app/winner2-
v1.16.jar
JnlpDownloadServlet(3): Generating JarDiff for winner2.jar
1.15->1.16
JnlpDownloadServlet(2): Failed to generate JarDiff for
winner2.jar 1.15->1.16


EXPECTED VERSUS ACTUAL BEHAVIOR :
I expect a jardiff file to be created, instead the full new
jar is returned in web start 1.2. In web start 1.0.1 a null
pointer exception is thrown.

I belive this all revolves around the call to
ServeltContext.getRealPath which returns null if the
context maps to a war file.

The fact that this threw a null pointer exception in web
start 1.0.1 but returns the full jar in web start 1.2 means
that this must have been a known bug that was looked at for
1.2.

However, this "fix" has effectively broken jar
differencing/incremental updates for applications that are
deployed in a war file.

ERROR MESSAGES/STACK TRACES THAT OCCUR :
JnlpDownloadServlet(3): Resource returned: /app/winner2-v1.16.jar
JnlpDownloadServlet(3): Generating JarDiff for winner2.jar 1.15->1.16
JnlpDownloadServlet(2): Failed to generate JarDiff for winner2.jar 1.15->1.16

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER WORKAROUND :
The only workaround I can find it to unpackage the
application on disk in tomcat. If it is left in the war
file jar differencing fails. This is not an acceptable
solution for our finished product.

Because we are relying on features in web start 1.2 we are
targetting jre 1.4.1, so I am hoping this issue will be
resolved by then. For our product we expect the difference
in size between new jars and jardiff files to be several
megabytes, so a fix for this is essential for us.
(Review ID: 159449) 
======================================================================
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: mantis mantis-b02 FIXED IN: mantis mantis-b02 INTEGRATED IN: mantis mantis-b02 mantis-b04
31-08-2004
WORK AROUND don't use war files ###@###.### 2002-08-05
05-08-2002
EVALUATION we cannot reproduce. Customer is being contacted to get more info. ###@###.### 2002-07-30 below is the email sent to the customer: From: Nathanael Thompson <###@###.###> To: ###@###.### Subject: Re: (Review ID: 159449) Jar Diff'ing does not work if jars are packaged in a war file. Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IM-Review-ID: 159449 Hi, We have been having trouble reproducing the bug on our systems. We have some more questions to ask you: You should put both versions of the jar in the same war file. Did you put them in a separate war file? That is, in order to generate jardiff between dummy__V1.3.jar and dummy__V1.2.jar, they should reside in the same war file. Not in two separate war files. This is because jardiff are used for versioning between the same application. Each war file represent a application. But if you did put the two different versions of the jar in a same war file, than that's a problem and we need your help to reproduce it. Also, what kind of web server is the customer using? Are you using tomcat too? Regards ###@###.### 2002-07-30 I can reproduce the problem with Tomcat 4.1.2. This is due to the fix for 4474021 only works for weblogic 6. Tomcat 4.1.2 implementation on how to handle WAR file is different. So the fix for 4474021 cannot apply. We should investigate for a generic solution to solve the problem. One possible way is instead of trying to figure out the URL -> real file path on different web servers implementation, we can just use the URL and request the file from the server again, this way we don't need to care about the actual file path. I don't think this is a showstopper since the servlet would not crash or anything, it just would not return jardiff for tomcat 4.1.2 when the users is using WAR files. I would suggest to commit this to mantis. ###@###.### 2002-07-31
31-07-2002