2009/7/9 <ma...@apache.org>: > Author: markt > Date: Thu Jul 9 09:06:51 2009 > New Revision: 792462 > > URL: http://svn.apache.org/viewvc?rev=792462&view=rev > Log: > Suggest alternative approach > > Modified: > tomcat/current/tc5.5.x/STATUS.txt > > (well, even now one can set CLASSPATH there, or add tools.jar to > common.loader of catalina.properties - haven't tried the latter) > Though we already have a switch that controlls configuration: "-security". > + markt: > + How about an alternative approach that removes the javac command > completely > + rather than trying to fix it? As has been pointed out, setenv can be > used to > + achieve the same end and is more consistent with how we do things now, >
Yes. I would like javac there to be removed completely. I would like adding tools.jar to the classpath to be also completely removed. How others think about it? The docs can then be made consistent with implementation. The way how tools.jar is added under Unix now (in setclasspath.sh) is definitely odd (both 5.5 and 6.0): if [ "$1" = "debug" -o "$1" = "javac" ] ; then CLASSPATH="$JAVA_HOME"/lib/tools.jar fi There is no need to add tools.jar when running with jdb. Jdb does not need it. Thus actually we can count it as never added, on Unix. Also, if CLASSPATH was set by user, the above code completely redefines it, and that is wrong. In Windows bat files the tools.jar is always added (in 5.5; with existence check in 6.0), but I won't mind removing it from there, for consistency, and as hardly anyone uses them in production. The exe installer on Windows (I tried the 5.5 one) does not add tools.jar to the classpath. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
