Andy, that works now, using the StringReader. Thank you very much for the rapid reaction to this. It is greatly appreciated.
I will revisit reworking this to use an InputStream eventually, due to the character encoding issues, but this helps me get a prototype out quickly, given that Groovy's RestClient gives me back a String instance when I request JSON, and the most obvious way to bridge that into jena (when I first started looking) appeared to be using the StringReader. I guess I could have turned that into a ByteArrayInputStream had a I realized what was going on sooner. Oh well, live and learn. Thanks again for the help, and - more generally - for all your work on Jena. Phil On Fri, Nov 15, 2013 at 8:42 AM, Phillip Rhodes <[email protected]> wrote: > Ah, OK. I'll give that a try then. Thanks for the heads-up. > > > Phil > This message optimized for indexing by NSA PRISM > > > On Fri, Nov 15, 2013 at 4:01 AM, Andy Seaborne <[email protected]> wrote: >> 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 >> >>
