You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by bu...@apache.org on 2002/08/27 23:31:33 UTC
DO NOT REPLY [Bug 12108] New: -
setclasspath.sh and catalina.sh should not used java.endorsed.dirs
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12108>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12108
setclasspath.sh and catalina.sh should not used java.endorsed.dirs
Summary: setclasspath.sh and catalina.sh should not used
java.endorsed.dirs
Product: Tomcat 4
Version: 4.1.9
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Other
Component: Catalina
AssignedTo: tomcat-dev@jakarta.apache.org
ReportedBy: ide@nlm.nih.gov
The current mechanism used by catalina.sh and setclasspath.sh to set
and then use environment symbol JAVA_ENDORSED_DIRS prevents users
from having their own endorsed directory -- and even prevents using
the j2sdk "default" endorsed dir of j2sdk/jre/lib/endorsed.
We have chosen to put our "endorsed" jar files into the sun advertised
location of j2sdk/jre/lib/endorsed -- but catalina.sh and setclasspath.sh
are ignoring that.
One option would be to have setclasspath.sh APPEND
to JAVA_ENDORSED_DIRS if it already exists, and if it doesn't, to
add the official sun location (jre/lib/endorsed) to the list before
adding the catalina specific directories.
(I don't love this solution, but I also don't love the entire "endorsed"
mechanism that sun has implemented.)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>