tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Luby <patrick.l...@sun.com>
Subject Re: Another proposal for java.ext.dirs
Date Tue, 02 Apr 2002 06:49:28 GMT
Costin,

costinm@covalent.net wrote:

> 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. 
> 


I have to admit that using the scripts is a messy way to handle this 
problem. I am still trying to find a way to get the java.endorsed.dirs 
property out of the scripts.


> 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.

 >

I agree. It is one of those tradeoffs: you can customize your JDK, but 
it may not work with your applications.


> 
> 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.


I don't think I will commit this proposed change. After thinking about 
it, I don't think a hacky script change is a real solution. Since this a 
problem that affects nearly all Java applications (ant complained  when 
I forgot to delete the jaxp.jar that I put in my jre/lib/ext directory), 
I am starting to think that this may be a problem where the cure is more 
painful than the problem.

Patrick


> 
> 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>
> 


-- 
________________________________________________________________
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>


Mime
View raw message