Bug #2481
closedNPE in XMLIndenter.java writing attribute with null value
100%
Description
saxon-version="9.6.0.7"
saxon-edition="HE"
java-version="1.8.0_40"
java-name="Java HotSpot(TM) 64-Bit Server VM"
Using the saxon Serializer, StreamWriterToReciever, with INDENT option which loads tehe XMLIndenter class.
This method throws an NPE
public void attribute(NodeName attName, SimpleType typeCode, CharSequence value, int locationId, int properties)
throws XPathException {
if (value.equals("preserve") && // --->>> if value is null here, does not need to be xml:space, NPE
attName.hasURI(NamespaceConstant.XML) &&
attName.getLocalPart().equals("space") &&
suppressedAtLevel < 0) {
// Note, we are suppressing indentation within an xml:space="preserve" region even if a descendant
// specifies xml:space="default
suppressedAtLevel = level;
}
bufferedAttributes.addAttribute(attName, typeCode, value.toString(), locationId, properties);
//nextReceiver.attribute(nameCode, typeCode, value, locationId, properties);
}
Without using the INDENT option then no NPE.
Details on request
Updated by Michael Kay about 9 years ago
Very strange one. The value parameter passed to the attribute() method on the Receiver pipeline should never be null. But I guess if the Receiver pipeline is getting its input directly from a StreamWriter, and the caller of the StreamWriter passes null as an attribute value, then it could happen. But that would be an API violation of some kind, so an NPE at some point would be appropriate.
Updated by David Lee about 9 years ago
Michael Kay wrote:
But that would be an API violation of some kind,
Yes, I'm passing a null, hence a low priority .. however
so an NPE at some point would be appropriate.
Many other places in the saxon code nulls for values converted to ""
This exact code works perfectly if I dont set the indenting property - the null value doesnt cause an NPE.
So if "an NPE at some point would be appropriate.", ideally it should be consistant.
(I'd vote for no NPE :)
Not a blocking bug as its clearly my code should not pass a null, but it took quite a while to discover
why the NPE in this one variant of a test case and not all the others.
Updated by Michael Kay about 9 years ago
I'm in a bit of a dilemma here, because the Javadoc for XMLStreamWriter in many cases says parameters "must not be null"; in a small number of cases (e.g. writing comments) it says "may be null", and in many other cases it says nothing. Where it does say "may be null" it fails to say what null is supposed to mean. Why comment text can be null and PI text can't is something of a mystery, and make it difficult to infer any kind of general policy. I'm going to take the stance that null is not allowed except where the spec explicitly says that it is, and will add checking on the methods of StreamWriterToReceiver to that effect. I will make this change for 9.7 but not for 9.6.
I'm very suprised that any path through the serializer should accept a null value for an attribute; the fact that there's one path that doesn't is no surprise at all.
Updated by Michael Kay about 9 years ago
- Status changed from New to Resolved
- Assignee set to Michael Kay
- Fixed in version set to 9.7
Added checks for null where appropriate in StreamWriterToReceiver for 9.7. No change to 9.6.
Updated by O'Neil Delpratt about 9 years ago
- Status changed from Resolved to Closed
- % Done changed from 0 to 100
- Fixed in version changed from 9.7 to 9.6.0.8
Updated by O'Neil Delpratt about 9 years ago
- Status changed from Closed to Resolved
- Found in version changed from 9.6.0.7 HE to 9.6
- Fixed in version deleted (
9.6.0.8)
Updated by O'Neil Delpratt about 9 years ago
- Status changed from Resolved to Closed
- Fixed in version set to 9.7.0.1
I am closing this one as fixed in the Saxon 9.7.0.1 release but not in the 9.6 branch
Please register to edit this issue