Hello Michael,
Done some 9.3.0.2 testing - like George we're also having problems with
newDocumentBuilder(), and we've also found a problem with SAXSource
input to XsltCompiler.compile:
Michael Kay wrote:
> I have uploaded a maintenance release (9.3.0.2).
>
>
Many thanks. I didn't say last time - many thanks for the s9api
improvements in the 9.3 release; some of them are very useful to us.
Unfortunately we have the same problem that George has already reported
with Processor.newDocumentBuilder().
I cut-down our code just to double check using the command-line,
resulting in a NoClassDefFoundError from:
public static void main(String[] args) {
Processor p= new Processor(false);
DocumentBuilder db= p.newDocumentBuilder();
}
> Keep the feedback coming.
>
OK - Another issue we've found... In 9.2 we were instantiating our own
parsers (in some cases to implement a 'bypass JAXP factories' mechanism)
and then using a SAXSource as input to the s9api compile methods, for
example:
XsltCompiler c= proc.newXsltCompiler();
XMLReader r= platformSpecific.getXmlReader();
XsltExecutble e= c.compile(new SAXSource(r, inputSource));
However in 9.3 we found that the XMLReader we were supplying as the
first argument to the SAXSource constructor was being ignored and a new
parser was instantiated (via JAXP).
Using the source code zip we tracked this down to
PreparedStylesheet.loadStylesheetModule. ParseOptions.getXMLReader()
(used in 9.3) and AugmentedSource().getXMLReader() (9.2) are not
functionally equivalent and so getConfiguration().getStyleParser() is
being called in 9.3 to create a new XMLReader.
We've figured out a work-around (wrapping the SAXSource in an
AugmentedSource and then calling .setXMLReader() on it, before calling
compile) and we've also got the xml-apis.jar work-around for the stream
classes - so we're not being held up.
Many thanks,
Nigel
--
Nigel Whitaker, DeltaXML: "Change control for XML"
nigel.whitaker@... http://www.deltaxml.com
Registered in England: 02528681 Reg. Office: Monsell House, WR8 0QN, UK
|