[
https://issues.apache.org/jira/browse/JENA-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290900#comment-13290900
]
Andy Seaborne commented on JENA-251:
------------------------------------
An immediate fix is to protect the call to the IRIResolver:
if ( baseIRI != null )
baseIRI = IRIResolver.resolveString(baseIRI) ;
so it does not NPE.
A relative IRI in the file causes
{E211} Base URI is null, but there are relative URIs to resolve.: <x>
as before.
I'm not sure there is a default we can sensibly choose. The non-RDF/XML parsers
default to the JVM base directory via IRIResolver.chooseBaseURI() but that is
rather arbitrary.
This operation is the path when the input stream is opened externally and so
responsibility for the baseURI is with the caller.
Status: fix applied: JIRA left open for discussion.
> IRI throws a NullPointerException when RiotLoader reads an RDF/XML file while
> using dependencies of jena-sb 1.3.4-SNAPSHOT
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JENA-251
> URL: https://issues.apache.org/jira/browse/JENA-251
> Project: Apache Jena
> Issue Type: Bug
> Components: RIOT
> Affects Versions: SDB 1.3.4
> Environment: Apache Maven 3.0.3
> Java version: 1.6.0_31, vendor: Apple Inc.
> OS name: "mac os x", version: "10.7.4", arch: "x86_64", family: "mac"
> Default locale: en_US, platform encoding: MacRoman
> Reporter: Mike Jones
> Attachments: Sample.tar.gz
>
>
> A project I'm working on loads files at runtime and updates URIs that have
> place holders with the domain a web application is deployed, prior to being
> saved to a default or named graph with SDB. For example, mca://foo/bar/
> becomes http://m.bristol.ac.uk/foo/bar/. After the jena-sdb version become
> 1.3.4-SNAPSHOT some of the RDF XML files were failing with the following
> exception:
> java.lang.NullPointerException
> at java.util.regex.Matcher.getTextLength(Matcher.java:1140)
> at java.util.regex.Matcher.reset(Matcher.java:291)
> at java.util.regex.Matcher.<init>(Matcher.java:211)
> at java.util.regex.Pattern.matcher(Pattern.java:888)
> at org.apache.jena.iri.impl.Parser.<init>(Parser.java:89)
> at org.apache.jena.iri.impl.IRIImpl.<init>(IRIImpl.java:65)
> at org.apache.jena.iri.impl.AbsIRIImpl.create(AbsIRIImpl.java:692)
> at org.apache.jena.iri.IRI.resolve(IRI.java:432)
> at
> org.openjena.riot.system.IRIResolver$IRIResolverNormal.resolveSilent(IRIResolver.java:435)
> at
> org.openjena.riot.system.IRIResolver$IRIResolverNormal.resolve(IRIResolver.java:420)
> at org.openjena.riot.system.IRIResolver.resolveIRI(IRIResolver.java:199)
> at
> org.openjena.riot.system.IRIResolver.resolveString(IRIResolver.java:189)
> at org.openjena.riot.RiotReader.createParserTriples(RiotReader.java:144)
> at org.openjena.riot.RiotLoader.readTriples(RiotLoader.java:215)
> I've created a reduced sample test case (using maven). If you use the
> dependencies linked to jena-sdb (1.3.4-SNAPSHOT) you will get the stack trace
> above with mvn test. If you replace the dependencies with jena-arq
> (2.9.0-incubating) and run mvn clean and mvn test you won't get an error but
> will see a list of URIs being printed to standard out.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
