tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: cvs commit: jakarta-tomcat-4.0/jasper/src/bin jasper.bat
Date Mon, 01 Apr 2002 18:45:59 GMT
On Mon, 1 Apr 2002, Patrick Luby wrote:

> Costin,
> The problem with the default JVM behavior can cause your application to 
> crash or behave in unexpected ways if there are incompatible jars 
> installed in the jre/lib/ext directory.

Then report the bug to the JVM people :-)

> The method that we are using is still compliant with the JDK 
> documentation in that we are using the documented way over overriding 
> the extensions via setting the "java.ext.dirs" property at startup. This 
> also the same type of override mechanism for the endorsed directories in 
> JDK 1.4.

> The only feature we are adding is the ability to add your extensions 
> back at the end of the classloader's search list.

I can live with having tomcat explicitely disable ext.dir - most people 
agree /ext is evil and it causes problems.

But adding it back with a different behavior is hardly 'compliant'.

The reason I disagree with removing ext - it makes tomcat even more 
dependent on startup script behavior, and adds another difference with the 
'normal' behavior for classloaders ( it already brakes one of the 
fundamental rules - the delegation ). 

> I am definitely not in favor of just letting the jre/lib/ext directory 
> sit at the front of the classloader's search list as that makes Tomcat 
> very sensitive (read breakable) due to the user's JVM configuration. 
> Hence, I believe that the "java.ext.dirs=" property setting should 
> remain. As to whether we should try to add back the extensions at the 
> end of the classloader's search list, I am not too picky about.

The ext/ was created with a purpose - and is a standard part of java.
If we don't like it - we can recommend the users to not use it, but
if the user does want to use it, it should operate the way it was 

> My first concern is that Tomcat always can at least run no matter what 
> extensions that user has installed. Whether or not those extensions are 
> accessible to Tomcat is, IMHO, a feature that we may or may not want to 
> include.

If the user installs some incompatible extensions - I think tomcat should 
report an error or not run. I'm ok with adding checks in tomcat to verify 
that the files in ext/ are compatible.


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message