> 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. > > 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 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. > > 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.
Fine, but your change creates problems (Jasper does not work on JDK 1.4 unless you delete common/endorsed/xerces.jar). I don't know why at this time, but it should be fixed ASAP. (Note: I don't care too much about this functionality ... Adding another CL layer is dangerous and makes CL slower; unless other people think this is useful I don't think we should add the feature) Remy -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
