Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 60969 invoked from network); 29 Apr 2002 04:20:12 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 29 Apr 2002 04:20:12 -0000 Received: (qmail 17143 invoked by uid 97); 29 Apr 2002 04:20:15 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 17126 invoked by uid 97); 29 Apr 2002 04:20:14 -0000 Mailing-List: contact tomcat-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Tomcat Developers List" Reply-To: "Tomcat Developers List" Delivered-To: mailing list tomcat-dev@jakarta.apache.org Received: (qmail 17112 invoked by uid 50); 29 Apr 2002 04:20:14 -0000 Date: 29 Apr 2002 04:20:14 -0000 Message-ID: <20020429042014.17111.qmail@nagoya.betaversion.org> From: bugzilla@apache.org To: tomcat-dev@jakarta.apache.org Cc: Subject: DO NOT REPLY [Bug 8611] New: - Sealed .jar files in WEB-INF/lib always fail to load second class X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT . ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8611 Sealed .jar files in WEB-INF/lib always fail to load second class Summary: Sealed .jar files in WEB-INF/lib always fail to load second class Product: Tomcat 4 Version: 4.0.3 Final Platform: PC OS/Version: Windows NT/2K Status: NEW Severity: Major Priority: Other Component: Catalina AssignedTo: tomcat-dev@jakarta.apache.org ReportedBy: dcox@cysive.com The webapp classloader (org.apache.catalina.loaderWebappClassLoader) appears to not handle sealed .jar files properly. On line 1598 (Revision 1.15.2.9) the call to definePackage passes entry.source as the URL that is the "sealBase" of the package. Everything is fine until a second class is loaded from the same package. On line 1614, the check to ensure a sealing violation is not occuring passes entry.source of the class being loaded. This check always fails because entry.source that the package was defined with was the *full* pathname to the classfile. The same holds true for the path being passed during the seal check. These URL's are never equal and therefore pkg.isSealed returns false on line 1614. As I am not in control of the .jar file that contains the sealed package I can't simply not seal it. This is the only reason I have given this a "major" priority. Please forgive if this was inappropriate... -- To unsubscribe, e-mail: For additional commands, e-mail: