Bug #4121


UnsupportedOperationException when writing to DOMResult

Added by Gunther Rademacher over 3 years ago. Updated about 3 years ago.

Start date:
Due date:
% Done:


Estimated time:
Legacy ID:
Applies to branch:
9.9, trunk
Fix Committed on Branch:
9.9, trunk
Fixed in Maintenance Release:


A transformer with a DOMResult may fail with an UnsupportedOperationException.

The attached test works OK with Saxon-HE 9.8, but fails with and

The actual exception is:

	at net.sf.saxon.event.Receiver.append(
	at net.sf.saxon.event.RegularSequenceChecker.append(
	at net.sf.saxon.event.ProxyReceiver.append(
	at net.sf.saxon.event.ComplexContentOutputter.append(
	at net.sf.saxon.expr.Expression.lambda$process$0(
	at net.sf.saxon.expr.Expression.process(
	at net.sf.saxon.expr.instruct.TemplateRule.applyLeavingTail(
	at net.sf.saxon.trans.Mode.applyTemplates(
	at net.sf.saxon.trans.XsltController.applyTemplates(
	at net.sf.saxon.s9api.AbstractXsltTransformer.applyTemplatesToSource(
	at net.sf.saxon.s9api.XsltTransformer.transform(
	at net.sf.saxon.jaxp.TransformerImpl.transform(
	at TestResults.testDomResult(

Files (2.74 KB) Gunther Rademacher, 2019-01-29 23:48
Actions #1

Updated by Michael Kay over 3 years ago

  • Status changed from New to In Progress
  • Assignee set to Michael Kay
  • Priority changed from Low to Normal

There were substantial changes in 9.9 to the interface between the Transformer and the Destination, prompted by the need to implement "sequence normalization" on the destination side (the main driver here was the introduction of the JSON and Adaptive output methods). The destination is now expected to handle any "regular sequence" which may include composed nodes as well as decomposed events, and it seems that the DomDestination is not doing this; it should insert a SequenceNormalizer into the pipeline but this is not happening, and as a result if composed nodes are sent across the interface they are rejected.

Incidentally it seems that we do have a RegularSequenceChecker in the pipeline in as issued. The idea was that this would only be included when needed for debugging, but it probably does no harm. Its sole function is to verify that the protocol between transformer and destination is being properly adhered to.

Actions #2

Updated by Michael Kay over 3 years ago

In DOMDestination.getReceiver(), changing

return domWriter;


return params.makeSequenceNormalizer(domWriter);

makes the test pass. Need to regression test. JUnit test case added as DomTest.testBug4121().

Actions #3

Updated by Michael Kay over 3 years ago

  • Category set to JAXP Java API
  • Status changed from In Progress to Resolved
  • Applies to branch trunk added
  • Fix Committed on Branch 9.9, trunk added
Actions #4

Updated by Gunther Rademacher over 3 years ago

Thank you for fixing this so quickly! It works fine now.

Actions #5

Updated by Emanuel Wlaschitz about 3 years ago

Just to let you know, we ran into the same issue on Saxon-HE (.NET), with a very similar stack trace. With the snippet posted above, we can work around this using

public class TextWriterDestination2 : TextWriterDestination
    public TextWriterDestination2(XmlWriter writer) : base(writer)

    public override Receiver getReceiver(PipelineConfiguration pipe, SerializationProperties value2)
        return value2.makeSequenceNormalizer(base.getReceiver(pipe, value2));

instead of using the built-in TextWriterDestination when serializing into a XmlWriter (such as one returned by XDocument.CreateWriter())

Actions #6

Updated by Michael Kay about 3 years ago

I've raised the new problem as bug #4166.

Actions #7

Updated by O'Neil Delpratt about 3 years ago

  • Status changed from Resolved to Closed
  • % Done changed from 0 to 100
  • Fixed in Maintenance Release added

Bug issue fixed in the Saxon maintenance release.

Please register to edit this issue

Also available in: Atom PDF