On 15/11/13 05:59, Phillip Rhodes wrote:
FWIW... I just grabbed the Jena source, imported it into my workspace
and set my project to reference that, so I could debug into this as
it's running. What I see is the code getting to line 864 in RDFDataMgr
and executing this code:
parser = RiotReader.createParser(tokenizer, lang, base, output) ;
which returns null. The next line tries to use the null reference,
and hence the NPE.
Looking at RiotReader.createParser(), I don't see anything in there
that mentions JSON-LD at all. But the docs for java-jsonld say
something like:
"JenaJSONLD must be initialized so that the readers and writers are
registered with Jena." and I do call the init() method. But I don't
see how that registration process plays with this createParser() code.
I'm guessing things have just gotten out of sync between Jena and the
JSON-LD stuff?
The problem is reading from a reader (I should have noticed this earlier
in the thread).
If you use an InputStream it will work (= it does for me).
Readers are troublesome because they fix the charset before Jena gets a
chance set the encodign according to syntax. A FileReader is
particularly troublesome because it fixes the charset as the system
default so if that is not UTF-8 (and it isn't on Windows) it will not be
UTF-8.
StringReader is only usecase but it currently follows a hardwired path
inside RDFDataMgr. The general ReaderRIOT interface does not have Readers.
Regrettably, I think I'll have to go and add Readers to ReaderRIOT (it
only results in parallel code - InputStream and Reader have no
commonality) just because of StringReader.
You should be able to pass the input stream from HTTP request to the
RDFDataMgr or model.read directly.
Andy
Phil
