[
https://issues.apache.org/jira/browse/JENA-1294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882758#comment-15882758
]
Andy Seaborne commented on JENA-1294:
-------------------------------------
Analysis:
If the first point of contact with Jena is the RDFS vocabulary then:
# Load RDFS, run its class init.
# While running class init, the class is not itself fully initialized.
# The first initialization is {{resource( "Class")}} which hits {{NodeFactory}}
causing {{JenaSystem.init()}} to run.
# This causes {{AssemblerUtils.init}] to run which depends on
{{RDFS.subClassOf}}, which is not yet initialized so it is null.
Moving the {{JenaSystem.init()}} does not help. RDFS is always initializing
while JenaSystem.init runs.
*<proposal>*
have forms of the RDFS constants that are not dependent on RDFS initializing.
These would be static methods (functions) that get called and calculate their
return, not cached static constants. (Prototyped and manually tested.)
OWL and RDF are also affected in fixable ways.
*</proposal>*
Another way is for assignment to the vocabulary constants to be explicitly done
from outside in some piece of initialization, but then the constants can't be
final. This is a neater way internally because it is a systematic solution, not
case-by-case, but at the cost of losing the {{final}} impacts applications and
is IMO too great.
This is not testable in any reliable way that I can think of! The problem only
arises when code first uses Jena via one of these 3 vocabularies. Tests running
in random orders don't show it and some of our test framework code itself
touches Jena before a test is run.
As to exactly why {{TestParameterizedSparqlString}} was being called first or
why running {{TestParameterizedSparqlString}} on its own now fails, I don't
know. I'm fairly sure I've run it separately recently before (for an earlier
initializer issue). Maybe there is some subtle internal JVM non-determinacy
and/or change causing a different order somewhere.
> 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: Critical
> 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)
