United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4720897 : Jar Diff'ing does not work if jars are packaged in a war file.

Details
Type:
Bug
Submit Date:
2002-07-25
Status:
Resolved
Updated Date:
2003-04-12
Project Name:
JDK
Resolved Date:
2002-10-15
Component:
deploy
OS:
windows_2000
Sub-Component:
webstart
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.2.0
Fixed Versions:
1.4.2 (mantis)

Related Reports

Sub Tasks

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
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
                                     
2002-07-31
WORK AROUND

don't use war files


###@###.### 2002-08-05
                                     
2002-08-05
CONVERTED DATA

BugTraq+ Release Management Values

COMMIT TO FIX:
mantis
mantis-b02

FIXED IN:
mantis
mantis-b02

INTEGRATED IN:
mantis
mantis-b02
mantis-b04


                                     
2004-08-31



Hardware and Software, Engineered to Work Together