Proposed patch for Tomcat 4.1: Replacing JarURLHandler with Ant's ZipFile class

2004-03-22 Thread Jochen Wiedmann
Hi,

in

 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26275

it turned out, that Tomcat suffers from a problem in Java's zip file
handling, which persists since years and most probably won't be fixed in the
next years. It also turned out, that the problem could be fixed by using
Ant's ZipFile class.
In the last days I inspected Tomcat's (4.1.30) sources for extracting WAR
files. To be honest, I find them a real mess. The design decision for
dealing with jar: and file: URL's seems to me to be severely broken,
because in the end it depends on an underlying File anyways.
Attached you find a patch, which is *not* necessary to fix bug 26275.
(Changes in ExtractWar would be sufficient.) However, I find it worth
looking at, because you'll easily see that replacing URL's with File's
reduces the code complexity quite much.
The attached patch is *not* ready for checkin, because I did not even
test it. (That's why I omitted the [PATCH] in the subject.) I just wanted a
first sign, whether it's worth to continue. If you don't like this work,
let me know and I'll return with a smaller fix for 26275.
Jochen



Only in c:\jwi\Workspace\jakarta-tomcat-4.1.30-src: .classpath
Only in c:\jwi\Workspace\jakarta-tomcat-4.1.30-src: .project
Only in c:\jwi\Workspace\jakarta-tomcat-4.1.30-src: bin
diff -ubr 
c:\tmp\jakarta-tomcat-4.1.30-src/catalina/src/share/org/apache/catalina/Deployer.java 
c:\jwi\Workspace\jakarta-tomcat-4.1.30-src/catalina/src/share/org/apache/catalina/Deployer.java
--- 
c:\tmp\jakarta-tomcat-4.1.30-src/catalina/src/share/org/apache/catalina/Deployer.java  
 2004-01-25 14:23:36.0 +0100
+++ 
c:\jwi\Workspace\jakarta-tomcat-4.1.30-src/catalina/src/share/org/apache/catalina/Deployer.java
 2004-03-15 05:06:46.858592000 +0100
@@ -65,6 +65,7 @@
 package org.apache.catalina;
 
 
+import java.io.File;
 import java.io.IOException;
 import java.net.URL;
 
@@ -117,22 +118,21 @@
 public String getName();
 
 
-/**
- * Install a new web application, whose web application archive is at the
- * specified URL, into this container with the specified context path.
- * A context path of  (the empty string) should be used for the root
- * application for this container.  Otherwise, the context path must
- * start with a slash.
- * p
- * If this application is successfully installed, a ContainerEvent of type
- * codeINSTALL_EVENT/code will be sent to all registered listeners,
- * with the newly created codeContext/code as an argument.
- *
- * @param contextPath The context path to which this application should
- *  be installed (must be unique)
- * @param war A URL of type jar: that points to a WAR file, or type
- *  file: that points to an unpacked directory structure containing
- *  the web application to be installed
+/** Install a new web application with the given context path. If this
+ * application is successfully installed, a [EMAIL PROTECTED] ContainerEvent} of
+ * type [EMAIL PROTECTED] #INSTALL_EVENT} will be sent to all registered
+ * listeners, with the newly created codeContext/code as an
+ * argument.
+ *
+ * @param contextPath The context path to which this application
+ *   should be installed (must be unique). A context path of 
+ *   (the empty string) should be used for containers root
+ *   application. Otherwise, the context path must start with a
+ *   slash.
+ * @param war The web application being installed. If the location
+ *   points to a file, then it is assumed, that the file contains
+ *   a web application archive. Otherwise, the location must point
+ *   to a directory with the extracted web application.
  *
  * @exception IllegalArgumentException if the specified context path
  *  is malformed (it must be  or start with a slash)
@@ -141,7 +141,7 @@
  * @exception IOException if an input/output error was encountered
  *  during installation
  */
-public void install(String contextPath, URL war) throws IOException;
+public void install(String contextPath, File war) throws IOException;
 
 
 /**
@@ -156,9 +156,10 @@
  *
  * @param config A URL that points to the context configuration file to
  *  be used for configuring the new Context
- * @param war A URL of type jar: that points to a WAR file, or type
- *  file: that points to an unpacked directory structure containing
- *  the web application to be installed
+ * @param war The web application being installed. If the location
+ *   points to a file, then it is assumed, that the file contains
+ *   a web application archive. Otherwise, the location must point
+ *   to a directory with the extracted web application.
  *
  * @exception IllegalArgumentException if one of the specified URLs is
  *  null
@@ -168,7 +169,7 @@
  * @exception IOException if an input/output error was encountered
  *  during 

Re: Proposed patch for Tomcat 4.1: Replacing JarURLHandler with Ant's ZipFile class

2004-03-22 Thread Remy Maucherat
Jochen Wiedmann wrote:
 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=26275

it turned out, that Tomcat suffers from a problem in Java's zip file
handling, which persists since years and most probably won't be fixed in 
the
next years. It also turned out, that the problem could be fixed by using
Ant's ZipFile class.

In the last days I inspected Tomcat's (4.1.30) sources for extracting WAR
files. To be honest, I find them a real mess. The design decision for
dealing with jar: and file: URL's seems to me to be severely broken,
because in the end it depends on an underlying File anyways.
Attached you find a patch, which is *not* necessary to fix bug 26275.
(Changes in ExtractWar would be sufficient.) However, I find it worth
looking at, because you'll easily see that replacing URL's with File's
reduces the code complexity quite much.
The attached patch is *not* ready for checkin, because I did not even
test it. (That's why I omitted the [PATCH] in the subject.) I just wanted a
first sign, whether it's worth to continue. If you don't like this work,
let me know and I'll return with a smaller fix for 26275.
-1. I don't like your patch, sorry.

Rémy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Re: Proposed patch for Tomcat 4.1: Replacing JarURLHandler with Ant's ZipFile class

2004-03-22 Thread MagicDraw Support Team
Hello Jochen Wiedmann [EMAIL PROTECTED]:

Thank you for your inquiry. This is an automated response from MagicDraw support team. 
We have received
your message regarding Proposed patch for Tomcat 4.1: Replacing JarURLHandler with 
Ant's
 ZipFile class

We would like to offer our sincere thanks to you for emailing us!

Your message has been recorded into our customer service database.

Our staff responds to messages during regular business hours European time,
although we also attempt to answer messages in the weekends whenever
possible. Messages are normally answered within one to two business days.

For even faster assistance, you can browse our FAQ list at:
http://www.magicdraw.com/faq.php

Sincerely,

MagicDraw Support Team


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]