Marco Brandizi created JENA-1634:
------------------------------------
Summary: StreamRDFWriter doesn't work with Lang or RDFFormat
default instances.
Key: JENA-1634
URL: https://issues.apache.org/jira/browse/JENA-1634
Project: Apache Jena
Issue Type: New Feature
Components: RIOT
Affects Versions: Jena 3.9.0
Reporter: Marco Brandizi
I have [some
code|https://github.com/Rothamsted/ondex-knet-builder/blob/master/modules/rdf-export-2/src/main/java/net/sourceforge/ondex/rdf/export/RDFFileExporter.java]
that writes RDF to a file, starting from a Model. This is invoked many times
over the same FileOutput stream, by many threads that are producing RDF in
parallel.
The output type can be selected by the invoker, by passing Lang or RDFFormat
instances. Because of the way it works, that output will be
RDFFormat.TURTLE_BLOCKS most of times. However, there might be cases of small
output, where the user might want to send in formats like Lang.RDFXML.
Now, the problem is in the latter case the StreamRDFWriter.getWriterStream()
doesn't work. I've isolated the issue
[here|https://github.com/marco-brandizi/jena-stream-writer-issue/blob/master/src/test/java/info/marcobrandizi/rdf/test/JenaWritersTest.java]:
I get messages like _"No serialization for language Lang:RDF/XML"_ and,
looking at the sources, it seems that StreamRDFWriter recognises only
Lang/RDFFormat instances set in its own registry.
The same languages/variants work fine when I use the RDFDataMgr approach. This
makes me guess/hope that data manager is able to work in a stream fashion, when
the received RDF variants supports it.
Whatever it is, I think this is wrong, or at least should be documented better,
in particular, the documentation should say what to do in a situation like
mine, where it's not known in advance if we're going to deal with streaming or
not. Ideally, StreamRDFWriter should fallback to non-streaming, or trigger a
specific exception when dealing with a streaming-incompatible format, so that
the invoker can take fallback actions.
I suppose this applies to reading too.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
