You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jena.apache.org by "Andy Seaborne (JIRA)" <ji...@apache.org> on 2017/02/21 14:38:44 UTC
[jira] [Commented] (JENA-1294) JenaSystem.init from RDFS throws
NPE, fails ARQ tests
[ https://issues.apache.org/jira/browse/JENA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15876067#comment-15876067 ]
Andy Seaborne commented on JENA-1294:
-------------------------------------
[~alexishuf],
Thank you for the analysis! I can reproduce this by running {{TestParameterizedSparqlString}} and you've enabled me to find a shorter test case:
{noformat}
public static void main(String... args) {
Object obj = RDFS.label;
}
{noformat}
Your fixes will work in the test case but I'm concerned there is a deeper problem of the initialization order. The test are often the place issue first arise (sometimes because the tests delve deep inside Jena, though in this case this is public API usage).
If initialization is trigger by starting at RDFS, then Jena initialization issues during that call but it is in class loading of RDFS so RDFS itself is not initialized and class initialization is switched off (Java - prevents A init B init A).
As to why this is occurring now, I don't know. We have nearly identical systems.
> JenaSystem.init from RDFS throws NPE, fails ARQ tests
> -----------------------------------------------------
>
> Key: JENA-1294
> URL: https://issues.apache.org/jira/browse/JENA-1294
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ, Core
> Affects Versions: Jena 3.2.0
> Environment: OpenJDK 1.8.0_121-b13
> Linux 4.9.8-1-ARCH #1 SMP PREEMPT x86_64 GNU/Linux
> Reporter: Alexis Armin Huf
> Assignee: Andy Seaborne
> Priority: Minor
> Attachments: call-init.patch, jena-rdfs-init.tar.gz, mvn-verify-arq-bug.log.gz, no-rdfs-on-init.patch
>
>
> As discussed in #JENA-1290, jena-arq tests failed but committers could not reproduce the issue. The cause was that for some reason the first test that ran on was {{TestParameterizedSparqlString.test_param_string_injection_01}}, and as the following stack trace shows, it reached {{JenaSystem.init}} from RDFS class initialization.
> At least 3 locations involved in core and ARQ initalization refer to {{RDFS.subClassOf}} and {{RDFS.member}} which are null and cannot be initialized because RDFS is already being initialized:
> {noformat}
> Init: JenaInitLevel0
> Init: InitJenaCore
> JenaCore.init - start
> RDF: http://www.w3.org/1999/02/22-rdf-syntax-ns#
> RDFS: http://www.w3.org/2000/01/rdf-schema#
> RDFS.subClassOf: null
> OWL: http://www.w3.org/2002/07/owl#
> JenaCore.init - finish
> Init: InitRIOT
> RIOT.init - start
> RIOT.init - finish
> Init: InitARQ
> ARQ.init - start
> ARQ.init - start.1
> ARQ.init - start.2
> ARQ.init - start.3
> ARQ.init - start.4
> AssemblerUtils.init - start
> AssemblerUtils.init.registerDataset - start
> implementWith(http://jena.hpl.hp.com/2005/11/Assembler#DefaultModel)
> RDFS.subClassOf==null: true
> nulls: 5876a9af 7993aa96 null e1204e1f
> java.lang.NullPointerException
> at org.apache.jena.rdf.model.impl.ModelCom.add(ModelCom.java:1192)
> at org.apache.jena.assembler.assemblers.AssemblerGroup$ExpandingAssemblerGroup.implementWith(AssemblerGroup.java:95)
> at org.apache.jena.assembler.ConstAssembler.general(ConstAssembler.java:137)
> at org.apache.jena.sparql.core.assembler.AssemblerUtils.registerDataset(AssemblerUtils.java:72)
> at org.apache.jena.sparql.core.assembler.AssemblerUtils.init(AssemblerUtils.java:61)
> at org.apache.jena.query.ARQ.init(ARQ.java:596)
> at org.apache.jena.sparql.system.InitARQ.start(InitARQ.java:29)
> at org.apache.jena.system.JenaSystem.lambda$init$2(JenaSystem.java:119)
> at java.util.ArrayList.forEach(ArrayList.java:1249)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:194)
> at org.apache.jena.system.JenaSystem.forEach(JenaSystem.java:171)
> at org.apache.jena.system.JenaSystem.init(JenaSystem.java:117)
> at org.apache.jena.graph.NodeFactory.<clinit>(NodeFactory.java:32)
> at org.apache.jena.rdf.model.impl.ResourceImpl.fresh(ResourceImpl.java:135)
> at org.apache.jena.rdf.model.impl.ResourceImpl.<init>(ResourceImpl.java:85)
> at org.apache.jena.rdf.model.ResourceFactory$Impl.createResource(ResourceFactory.java:297)
> at org.apache.jena.rdf.model.ResourceFactory.createResource(ResourceFactory.java:92)
> at org.apache.jena.vocabulary.RDFS.resource(RDFS.java:36)
> at org.apache.jena.vocabulary.RDFS.<clinit>(RDFS.java:44)
> at org.apache.jena.shared.PrefixMapping.<clinit>(PrefixMapping.java:219)
> at org.apache.jena.query.TestParameterizedSparqlString.test_param_string_injection_01(TestParameterizedSparqlString.java:1382)
> {noformat}
> The same problem can be observed on a one-liner mwe (jena-rdfs-init):
> {noformat}
> public class App {
> public static void main(String[] args) {
> System.out.printf("subClassOf URI: %s\n", RDFS.subClassOf.toString());
> }
> }
> {noformat}
> The ARQ test issue can be fixed adding a call to {{JenaSystem.init}} (call-init.patch). However, if test order changes for someone, the problem re-appears.
> For Both the MWE and the test, replacing RDFS fields used in init code with {{RDF.getURI()+"localName"}} fixes it (no-rdfs-on-init.patch). It is a hack and the problem remains for if the MWE uses vocab classes (RDF and OWL) in place of RDFS.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)