Project

Profile

Help

Bug #2481

closed

NPE in XMLIndenter.java writing attribute with null value

Added by David Lee about 9 years ago. Updated about 9 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
s9api API
Sprint/Milestone:
-
Start date:
2015-10-22
Due date:
% Done:

100%

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

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

Actions #1

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.

Actions #2

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.

Actions #3

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.

Actions #4

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.

Actions #5

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
Actions #6

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)
Actions #7

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

Also available in: Atom PDF