I don't have any problem defaulting to RIOT readers, and I understand that the setting of the reader factory is in the ModelCom init.
However the test cases for Graph had tests that looked for the exception to be thrown, thus my thought that there was a contract that was not being kept. I will adjust the test case to ignore the case where the exception is thrown and will see if I can narrow it down to checking for just the one we expect to see. Claude On Sat, Jan 4, 2014 at 12:20 PM, Andy Seaborne (JIRA) <[email protected]>wrote: > > [ > https://issues.apache.org/jira/browse/JENA-618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13862282#comment-13862282] > > Andy Seaborne commented on JENA-618: > ------------------------------------ > > Claude - > > IO_JenaReaders.wireIntoJena is called during initialization implicitly. > If you put a breakpoint on IO_JenaReaders.wireIntoJena you'll see when > this is called (from ModelCom.<init>). > > A different viewpoint is that IO_JenaReaders.resetJena() is an emergency > get-out in case the switch to RIOT was a problem so a workaround was > available while a maintenance release was done. It is no in a public API. > From the lack of user list messages, it looks like RIOT has not been a > problem. > > I would much rather merge the codebases now and work forwards. We could > strip out the unused, out-of-date, and now not comformant, reader/writer > code as well (NT, TTL, N3). > > We could have a discussion of the contract for relative URIs and also on > warnings and errors in parsing but point-by-point defect reports to extract > beliefs isn't very efficient. > > (see the question "Why is it an ERROR when the code recovers and > continues?".) > > The old world RDFReaderF design does not work very well because > > # At odds with HTTP content negotiation. > # Does not address non-triples languages. > # The table of implementations is very hard to extend even for triples > languages. > # String names for languages get confused with base names in API calls. > # The flexibility to add custom readers per model is not used. It simply > is not something that has any meaning. (Maybe a possibility years ago but > the world has done a different way.) > > For 1 - take a look at the operation {{model.read(url)}} in the core-only > world. It chooses the reader implementation (RDF/XML) then tries to open > the URL. > > With RIOT, it makes the HTTP call, looks at the content-type (old world > does not use MIME types), then makes a decision on syntax by going to an > extensible registry. > > > > > calling IO_JenaReaders.wireIntoJena() and RDFReaderFImpl.reset() does > not reset the reader properly > > > --------------------------------------------------------------------------------------------------- > > > > Key: JENA-618 > > URL: https://issues.apache.org/jira/browse/JENA-618 > > Project: Apache Jena > > Issue Type: Bug > > Affects Versions: Jena 2.11.1 > > Reporter: Claude Warren > > Priority: Minor > > Attachments: test.java, test2.java > > > > > > Calling IO_JenaReaders.wireIntoJena() and then RDFReaderFImpl.reset() > yeilds an RDF reader that does not fail when a relative URI is read. > > It does report a warning if logging is enabled. > > > > -- > This message was sent by Atlassian JIRA > (v6.1.5#6160) > -- I like: Like Like - The likeliest place on the web<http://like-like.xenei.com> LinkedIn: http://www.linkedin.com/in/claudewarren
