You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by bu...@apache.org on 2003/02/13 01:04:53 UTC

DO NOT REPLY [Bug 17030] New: - URIResolver class not found with JDK 1.4.1

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

URIResolver class not found with JDK 1.4.1

           Summary: URIResolver class not found with JDK 1.4.1
           Product: XalanJ2
           Version: 2.4
          Platform: Other
        OS/Version: Other
            Status: NEW
          Severity: Normal
          Priority: Other
         Component: org.apache.xalan.xsltc
        AssignedTo: xalan-dev@xml.apache.org
        ReportedBy: andrzej@chaeron.com


I tried to run an XSLT transform using the latest Xalan 2.4.1 release and


the new JDK 1.4.1




Ran into some interesting issues.  




I know that JDK 1.4.1 packages an older version of Xalan with the


distribution (why is another question).  So I placed the appropriate Xalan


jars from the 2.4.1 release into the <java home>/jre/lib/endorsed


directory.




But Xalan kept telling me it couldn't find the class I had specified in


the -URIRESOLVER command line definition.  Worked fine under JDK 1.3.1. 


Huh?




I finally figured out that I needed to put the jar file that contains my


URIResolver implementation class in the endorsed directory as well.




Now this sucks big time.  My URIResolver class is in the com.chaeron.xsl


package, and so is not overriding anything that the JDK is using, and so


should not have to be placed in the endorsed directory.




It seems from the Xalan 2.4.1 source, it just does a Class.forName()


method invocation with only the URIResolver class name passed in.  I'm


guessing that the 1.4.1 JDK only checks the bootclasspath and thus


endorsed directory for classes, and does not try to load anything from the


normal classpath.




Can anyone verify this theory as being correct?




I suppse the Xalan folks could fix the issue by using up the correct


classloader....but they really shouldn't have to.  What was Sun thinking


when they came up with this aberration called "endorsed classes"?




<sheesh>