On 15/03/16 22:47, Jaroslav Pullmann wrote:
Hello Andy,
The error in tests 2 and 3 looks like it is because Jena initialization
has not happened.
The default is to use ServiceLoader which looks for META-INF/services/
org.apache.jena.system.JenaSubsystemLifecycle
Apparently there was an effort to fix this in the combined Jena-OSGI bundle
which META-INF/services/org.apache.jena.system.JenaSubsystemLifecycle
configuration already lists the main subsystems in the appropriate order:
org.apache.jena.system.InitJenaCore
org.apache.jena.riot.system.InitRIOT
org.apache.jena.sparql.system.InitARQ
org.apache.jena.tdb.sys.InitTDB
Can you debug enough to see if ARQ.init is bing called from InitARQ?
The NPE can come from getContext() returning null
and getContext() is not null if ARQ.init has been called because
defaultSettings() unconditionally creates a Context object.
I am wondering whether and how Jena v3 is used in OSGi environments so far?
We know that it is only a small %-age of the downloads. There is a good
chance that people are also packaging their own setups because the
bundles are right for them.
Having feedback and fixes is essential to keep a module usable.
> Or you can inject a different procedure with JenaSystem.setSubsystemRegistry
This seems the only option to explicitly debug and configure the
initialization in an OSGi runtime.
Thanks for the reference!
Jaro
