Bug #2642: NPE when using net.sf.saxon.event.EventSource in Saxon 9.7 - Saxon - Saxonica Developer Community

Actions

Send by e-mail Copy link

Bug #2642

closed

NPE when using net.sf.saxon.event.EventSource in Saxon 9.7

Added by Gunther Rademacher over 8 years ago. Updated over 7 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Michael Kay

Category:

Streaming

Sprint/Milestone:

Start date:

2016-02-24

Due date:

% Done:

100%

Estimated time:

Legacy ID:

Applies to branch:

9.7, trunk

Fix Committed on Branch:

9.7, trunk

Fixed in Maintenance Release:

9.7.0.7

Platforms:

Description

For mapping non-XML content to XML, we have been extending net.sf.saxon.event.EventSource. Per our standard XQuery pattern, the source was accessed via saxon:stream. This currently works in our product on Saxon-EE 9.6.0.5J.

While testing with 9.7.0.3J, I found that this approach now stopped to work with a NullPointerException from calling startElement of the Receiver.

A complete test case is attached.

While testing, I found that even in 9.6.0.5J, I get a NPE when I omit 'saxon:stream' from the query. In that case I think it is due to Configuration.resolveSource returning null for an EventSource. This call does not happen with 'saxon:stream' in place.

Thanks,

Gunther

Files

TestSaxonStreamOnEventSource97.java (2.97 KB) TestSaxonStreamOnEventSource97.java

TestNG test reproducing NPE from EventSource.send

Gunther Rademacher, 2016-02-24 11:43

Actions

Copy link

Updated by Michael Kay over 8 years ago

Thanks, will investigate. I'm having trouble remembering what the purpose of EventSource was, but I'm sure it will come back to me...

Actions

Copy link

Updated by Gunther Rademacher over 8 years ago

Here is a stack trace from the exception:

Exception in thread "Thread-0" java.lang.NullPointerException
        at com.saxonica.ee.stream.watch.WatchManager.startElement(WatchManager.java:248)
        at net.sf.saxon.event.StartTagBuffer.startContent(StartTagBuffer.java:236)
        at com.saxonica.ee.stream.ContentDetector.flush(ContentDetector.java:97)
        at com.saxonica.ee.stream.ContentDetector.startElement(ContentDetector.java:33)
        at net.sf.saxon.event.Stripper.startElement(Stripper.java:111)
        at TestSaxonStreamOnEventSource97$1$1.send(TestSaxonStreamOnEventSource97.java:45)
        at net.sf.saxon.event.Sender.send(Sender.java:148)
        at net.sf.saxon.functions.DocumentFn.sendDoc(DocumentFn.java:758)
        at com.saxonica.ee.stream.StreamInstr.processLeavingTail(StreamInstr.java:391)
        at net.sf.saxon.expr.instruct.Instruction.process(Instruction.java:149)
        at com.saxonica.ee.stream.PushToPull$Provider.run(PushToPull.java:92)
        at java.lang.Thread.run(Thread.java:745)

The test program does not terminate after the exception has been logged.

Actions

Copy link

Updated by Michael Kay over 8 years ago

Category set to Streaming
Status changed from New to AwaitingInfo
Assignee set to Michael Kay

The test case is failing because the user-supplied implementation of Location.saveLocation() returns null.

The contract for Location.saveLocation() is that it should return an immutable Location containing the same information as the target of the call. (The idea is to allow a mutable Location object to be supplied, thus avoiding the costs of creating lots of Location objects which might never be used, until such time as the system needs to save the data somewhere; an immutable implementation of Location can return "this", but a mutable one should copy itself.)

Actions

Copy link

Updated by Gunther Rademacher over 8 years ago

Thank you for investigating this. My apologies for having guessed the "not available" behaviour of Location, instead of looking up the definition.

I have now modified saveLocation to return this and getColumn/LineNumber to return @-1@. This eliminates the failures from all of our primary tests involving EventSource.

All of those tests read from an EventSource via saxon:stream, as shown in the attached test.

But when removing saxon:stream from the query, I am getting this NPE which I think is related to Configuration.resolveSource. That happens with 9.6.0.5, too.

Thanks again!

Actions

Copy link

Updated by Michael Kay over 8 years ago

Status changed from AwaitingInfo to Resolved
Priority changed from Low to Normal
Applies to branch 9.7, 9.8 added
Fix Committed on Branch 9.7, 9.8 added

Sorry this bug has been in limbo for so long, for some reason it was misclassified as "awaiting Info".

The test case now runs in both streaming and non-streaming mode. As well as the fixes to the Location object mentioned earlier, I had to

(a) patch Configuration.resolveSource() to recognize EventSource, and (b) change the implementation of EventSource to issue receiver.open() and receiver.close() calls.

Fixed on the 9.7 and 9.8 branches.

Actions

Copy link