tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Konstantin Kolinko <>
Subject Re: svn commit: r792462 - /tomcat/current/tc5.5.x/STATUS.txt
Date Thu, 09 Jul 2009 21:53:04 GMT
2009/7/9  <>:
> Author: markt
> Date: Thu Jul  9 09:06:51 2009
> New Revision: 792462
> URL:
> 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 - 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 is
definitely odd (both 5.5 and 6.0):
if [ "$1" = "debug" -o "$1" = "javac" ] ; then
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:
For additional commands, e-mail:

View raw message