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>