tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <cost...@covalent.net>
Subject Re: Another proposal for java.ext.dirs
Date Mon, 01 Apr 2002 22:16:42 GMT
Patrick,

Are you sure we need all this ? The .sh/.bat is already too complex.

A simple check ( in java ) for the things that we care about should be 
more than enough, adding another config option and env variable is too 
much. 

The intent of the ext/ is to simplify the user's life - so they don't have 
to set CLASSPATH. It doesn't work out in most cases.

If we want to disable it - fine, but I don't like making the user's life 
even harder by forcing him to remember and set yet another env variable.
I expect the 'regular' user will use ext/, most advanced users are well
aware of the problems and they already know how to deal with that. 

I remain -0 - if you really think this is a problem that must be solved,
I won't veto it.

Costin


On Mon, 1 Apr 2002, Patrick Luby wrote:

> All,
> 
> I admit my previous method for protecting Tomcat from conflicting system 
>   extensions proved to be a bit flawed. However, I still would like to 
> add  some protection against these conflicts since this tends to be a 
> difficult to diagnose problem for a lot of new Tomcat users. On the 
> other hand, I don't think we want to prevent knowledgable users from 
> using their installed extensions to support their installation.
> 
> So, here is what I propose. Note that I am in favor of checking the 
> installed extensions so this proposal should be complimentary to any 
> checking that might be implemented in the Tomcat code:
> 
> 1. Add the following to each Java execution line in the wrapper scripts:
> 
>     Unix:
>        -Djava.ext.dirs="$JAVA_EXT_DIRS"
>     Windows:
>        -Djava.ext.dirs="%JAVA_EXT_DIRS%"
> 
> 2. Add the following lines in setclasspath.bat and setclasspath.sh:
> 
>     Unix:
>        if [ -z "$JAVA_EXT_DIRS" ]; then
>          echo "Disabling installed Java extensions. Set the"
>          echo "JAVA_EXT_DIRS environment variable to the following 
> value"
>          echo "to enable installed Java extensions:"
>          echo "    $JAVA_HOME/jre/lib/ext"
>        fi
>     Windows:
>        if not "%JAVA_EXT_DIRS%" == "" goto gotJavaExtDirs
>        echo Disabling installed Java extensions. Set the
>        echo JAVA_EXT_DIRS environment variable to the following value 
> 
>        echo to enable installed Java extensions:
>        echo     %JAVA_HOME%\jre\lib\ext
>        :gotJavaExtDirs
> 
> 3. If the user does not defined JAVA_EXT_DIRS (the default case), the
>     java.ext.dirs property is set to "" and the above status message is
>     printed. Then, if the user defines JAVA_EXT_DIRS, the existing
>     behavior is enabled.
> 
> Since new Tomcat users primarily use the installed scripts, this is a 
> good way to protect Tomcat without preventing other custom scripts or 
> launchers from enforcing a different standard.
> 
> Does this sound like a reasonable approach? It would be nice to have 
> this property setting in the Bootstrap.java class, but unfortunately, 
> you must set the java.endorsed.dirs property when the JVM is started as 
> it is immediately put in the JVM's bootstrap classpath.
> 
> Thanks,
> 
> Patrick
> 
> ________________________________________________________________
> Patrick Luby                     Email: patrick.luby@sun.com
> Sun Microsystems                         Phone: 408-276-7471
> 901 San Antonio Road, USCA14-303
> Palo Alto, CA 94303-4900
> ________________________________________________________________
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>
> 
> 


--
To unsubscribe, e-mail:   <mailto:tomcat-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-dev-help@jakarta.apache.org>


Mime
View raw message