Tom -- Thanks for this info. I looked into it because I thought it might have to do with our classloader strategy. It doesn't. However, I do think that this class was in our D11 jar. Our build.xml file excludes this class if Xerces is not in the classpath at the time that Ant is run to do the build. It's possible that Sun did its own XalanJ build in preparation for JDK 1.4 and used our build.xml but did -not- have Xerces in the classpath at the time that Ant was run. This would build a XalanJ .jar without the IncrementalSAXSource_Xerces.
This change was made by Costin at build.xml rev 1.120 so that there would be no compile-time dependencies between Xalan and Xerces. Although including the class would have resulted in no run-time dependencies, there would still have been a compile-time dependency which Costin did not want, as I recall. So, thanks for bringing this up. It is good to know as someone else may want to replace only Xerces and not Xalan in the Sun JDK. For now, I'd say "Don't Do That." HTH, Gary > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, July 17, 2002 8:05 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: Xerces, Xalan, and 1.4.x JDK's > > > Hi, > > By now we are all becoming familiar with the story that there > are problems attempting > to run the latest Xalan from Apache with Sun's 1.4.x JDK > because an older version > of Xalan (2.2D11) is built into the rt.jar along with the > Crimson parser. > > Yesterday I ran into an interesting problem with Xerces and Xalan > in this context. If you put current versions of both > xalan.jar and xercesImpl.jar > on the command line classpath or in the ...jre/lib/endorsed > dir, it works fine. > The old xalan and crimson classes in rt.jar are ignored. But > if you just put > xercesImpl.jar on the command line or in the endorsed dir, > the following error is thrown. > > java.lang.ClassNotFoundException: > org/apache/xml/dtm/ref/IncrementalSAXSource_Xerces > at java.lang.Class.forName0(Native Method) > at java.lang.Class.forName(Class.java:135) > at > org.apache.xml.dtm.ref.DTMManagerDefault.getDTM(DTMManagerDefa > ult.java:269) > at > org.apache.xalan.transformer.TransformerImpl.transform(Transfo > rmerImpl.java:630) > at > org.apache.xalan.transformer.TransformerImpl.transform(Transfo > rmerImpl.java:1088) > at > org.apache.xalan.transformer.TransformerImpl.transform(Transfo > rmerImpl.java:1066) > at org.apache.xalan.xslt.Process.main(Process.java:865) > > Of course at first, the error seemed inexplicable, but if you > look at DTMManagerDefault.java, it has the following code > > boolean haveXercesParser = > (null != reader) > && > (reader.getClass().getName().equals("org.apache.xerces.parsers > .SAXParser") ); > > > So it looks like Xalan wants to load the > IncrementalSAXSource_Xerces class when it detects > an available Xerces parser and this class is not in the > built-in D11 Xalan (it is in the current > xalan.jar though). Maybe the location of that class has > changed? Looks like this reflects > a problem with an older version of Xalan trying to use a > newer Xerces parser. I'm not > sure what this means or whether anything needs to be changed > in Xalan going forward. Just wanted to bring it to your attention. > > Tom >
