From tomcat-dev-return-8037-qmlist-jakarta-archive-tomcat-dev=jakarta.apache.org@jakarta.apache.org Mon Apr 01 19:08:31 2002 Return-Path: Delivered-To: apmail-jakarta-tomcat-dev-archive@apache.org Received: (qmail 67711 invoked from network); 1 Apr 2002 19:08:31 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 1 Apr 2002 19:08:31 -0000 Received: (qmail 12761 invoked by uid 97); 1 Apr 2002 19:08:29 -0000 Delivered-To: qmlist-jakarta-archive-tomcat-dev@jakarta.apache.org Received: (qmail 12717 invoked by uid 97); 1 Apr 2002 19:08:28 -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 12706 invoked from network); 1 Apr 2002 19:08:28 -0000 X-Authentication-Warning: localhost.localdomain: costinm owned process doing -bs Date: Mon, 1 Apr 2002 11:06:17 -0800 (PST) From: X-X-Sender: To: Tomcat Developers List Subject: Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh In-Reply-To: <3CA8ABD3.5040904@sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Mon, 1 Apr 2002, Patrick Luby wrote: > BTW, I can eliminate the use of a separate classloader and put the > jre/lib/ext directory in the existing catalinaLoader and sharedLoader > instances. However, to do this, I need to change the getClassPath() > method in JspEngineContext.java so that it returns a classpath that > is consistent with the classloaders' search order. Right now, the > getClassPath() method (which is used for all JSP compilation) returns > a classpath in the exact opposite order of the order used by the > sharedLoader classloader. > > I originally put the extra classloader in to work around this > getClassPath() bug. However, given the JDK 1.4 differences in the > classloader delegation behavior, I think it would be better for me > to fix the getClassPath() problem and move the jre/lib/ext directory > into the existing catalinaLoader and sharedLoader instances like we > do for the endorsed directories. > > Costin, > > Does this sound reasonable to you? No. You can edit the doc - and use big font to tell users not to use ext/, or add a small check at startup and verify the servlet version. Changing the behavior of ext/ and class loader is the wrong solution, and shouldn't be done. Are you sure it doesn't have security implications ? JDK/ext can be protected and may have site-specific sensitive libraries. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: