Project

Profile

Help

Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues

Added by Srinivas M over 1 year ago

Hi,

We have upgraded Saxon-HE from 9.9.1-5 to the 11.4 version and the build is failing with the below errors:

symbol: class DocumentInfo location: package net.sf.saxon.om XMLUtils.java:48: error: cannot find symbol import net.sf.saxon.om.DocumentInfo;

symbol: class ReceiverOptions location: package net.sf.saxon.event AdaptersMappingNamespaceReducer.java:9: error: cannot find symbol import net.sf.saxon.event.ReceiverOptions;

symbol: class Location location: package net.sf.saxon.expr.parser AdaptersMappingNamespaceReducer.java:10: error: cannot find symbol import net.sf.saxon.expr.parser.Location;

I found that DocumentInfo moved as TreeInfo from one of the community-post. But, could not find the details for the other classes. Is there any migration guide available for these changes?

Any help would be greatly appreciated.

Thanks, Srinivas


Replies (5)

Please register to reply

RE: Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues - Added by Michael Kay over 1 year ago

No, I'm sorry, if you write applications that dive into Saxon below the level of the s9api API (or other public APIs such as JAXP and XQJ), then you're very much left to your own devices when migrating to a new release. We do outline most of the more significant changes in the change log (see https://www.saxonica.com/documentation11/index.html#!changes/spi/9.9-11.1 ), but you probably won't find everything there.

ReceiverOptions seems to have been renamed ReceiverOption. I guess that wasn't deliberate; I think we experimented with a different design, and then reverted to the original, and the name got accidentally changed in the process.

Location is now in the s9api package, presumably because we decided to make it part of the public API.

RE: Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues - Added by Srinivas M over 1 year ago

Hi Michael,

Thanks a lot for your quick reply.

I have couple more questions as shown below:

We were computing XPath and returning as SequenceExtent but it moved as an abstract class in the latest version.

public SequenceExtent computeXPath(NodeInfo nodeInfo, String xpathExpression) throws TransformerException {

		XPathExpression expr = (XPathExpression) retrieveExpression(xpathExpression);
		SequenceIterator iter = expr.iterate(expr.createDynamicContext(nodeInfo));
		return new SequenceExtent(iter);
	}

We were setting errorListener on the Configuration class using the setErrorListener method, but it is removed now

private static Configuration m_xpath_configuration = new Configuration();
	private static Configuration m_xslt_configuration = new Configuration();

	private static TransformerFactory m_tfrmFactory;
	static {
		// Set the ErrorListener to override the StandardErrorListener.
		Log LOG = LogFactory.getLog(MappingConstants.SAXON_LOG_NAME);
		SaxonErrorListener errorListener = new SaxonErrorListener(LOG);
		m_xslt_configuration.setErrorListener(errorListener);
		m_xpath_configuration.setErrorListener(errorListener);

Could you please suggest alternatives for the above scenarios?

Thanks, Srinivas

RE: Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues - Added by Michael Kay over 1 year ago

Well, the best option would be to move everything up to the s9api level so you are using stable APIs.

But short of that, I'd suggest replacing SequenceExtent with GroundedValue, you can get a GroundedValue from a SequenceIterator using the static method SequenceTool.toGroundedValue().

As for the ErrorListener, we removed it from the Configuration level because there's really no way of implementing it in a way that is thread-safe: in the JAXP setup, if you run multiple compilations or transformations within the scope of a single TransformerFactory, your ErrorListener has no way of knowing what actually failed. You should associate separate ErrorListeners (or ErrorReporters) with individual compilation and execution tasks so they don't interfere with each other.

RE: Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues - Added by Srinivas M over 1 year ago

Thanks, Michael,

Sorry for bothering you.

setWriter method is removed from Emitter abstract class and I see setUnicodeWriter instead. So, do we need to setUnicodeWriter and pass UnicodeWriter? or is there any other best alternative way?

our code snippet:

XMLEmitter xmlEmitter = new XMLEmitter();
			xmlEmitter.setPipelineConfiguration(pc);
			xmlEmitter.setWriter(writer);
			xmlEmitter.setOutputProperties(outputProperties);

RE: Saxon-HE:9.9.1-5 to Saxon-HE:11.4 upgrade issues - Added by Michael Kay over 1 year ago

There is an implementation of UnicodeWriter that wraps a Writer (`UnicodeWriterToWriter). Just use that. But if you're writing UTF8, use the UTF8Writer which is more efficient.

I'm afraid if you are trying to interact with Saxon using low-level interfaces like this, you have to be prepared to dig around the source code and work out how to fix things.

    (1-5/5)

    Please register to reply