tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat jasper.sh
Date Mon, 01 Apr 2002 19:06:17 GMT
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:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message