On Mon, 1 Apr 2002, Patrick Luby wrote: > Remy and Costin, > > I will reverse the patch since there are enough -1s on this. One > question: should we continue to set the "-Djava.ext.dirs=" in the > wrapper scripts? This disables the extensions but without any code > change to Tomcat. Or do we want to revert back to the original > scripts where the extensions are enabled by default?
I don't think we should disable ext/ - we can recommend people to not use it ( unless they know what they're doing ). If someone chooses to use ext/, he expect it to work - because that's what the java doc says. I'm -0, since we do disable CLASSPATH in the script. In general I think it's better to minimize the number of special settings in the command line. The .sh/.bat is just one way to start tomcat, there are implications when you embed it, start it with wrapper or from other apps, etc. If you really want to have fun with the startup, it would be better to remove more 'special' behaviors from .sh/.bat and clearly documenting what remains - i.e. the java options and classpath that are required to start tomcat. Costin > > Patrick > > Remy Maucherat wrote: > > >>>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 > >>> > >>> > >>> > >>I think I found the problem. In JDK 1.4, the StandardClassLoader's > >> > >>loadClass() method appears to be unconditionally delegating to its > >> > >>parent classloader even when setDelegate is set to false. This > >>appears to be caused by changes to the URLClassLoader class in JDK > >>1.4. > >> > > > > I had missed that it was attempting to change the delegation model > > (apparently, Costin didn't, that's why he was complaining, I suppose ;-)). > > I'm -1 for the patch then; please revert it. The use case is clearly not > > worth introducing non-compliant behavior; I fully agree with Costin here: if > > the ext mechanism is broken, then it's up to the JDK to fix it. > > > > Remy > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
