On 17/12/13 08:35, Rupert Westenthaler wrote:
Hi Clerezza & Stanbol Community
This morning I looked into the last two integration tests failing in
the trunk version. One of those was related to the SPARQL endpoint of
the Stanbol Enhancer that allows to perform SPARQL queries on the
Enhancer configuration.
First I throughout this was caused by some classpath problems related
to Xerces in the Jena TDB bundle as I was getting
Caused by: java.lang.NoClassDefFoundError: Could not initialize
class com.hp.hpl.jena.sparql.expr.NodeValue
at com.hp.hpl.jena.sparql.expr.ExprVar.eval(ExprVar.java:65)
[..]
at
org.apache.clerezza.rdf.jena.sparql.ResultSetWrapper.<init>(ResultSetWrapper.java:40)
at
org.apache.clerezza.rdf.jena.sparql.JenaSparqlEngine.execute(JenaSparqlEngine.java:84)
at
org.apache.stanbol.enhancer.jersey.resource.EnhancerRootResource$EnhancerResource.sparql(EnhancerRootResource.java:160)
[..]
However when you restart Stanbol so that this error appears the first
time you can see a completely different stack trace:
Caused by: org.glassfish.jersey.server.ContainerException:
java.lang.ExceptionInInitializerError
at
org.glassfish.jersey.servlet.internal.ResponseWriter.rethrow(ResponseWriter.java:230)
[..]
Caused by: java.lang.ExceptionInInitializerError
at com.hp.hpl.jena.sparql.expr.ExprVar.eval(ExprVar.java:65)
[..]
Caused by: java.security.AccessControlException: access denied
("java.io.FilePermission"
"/Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre:lib:jaxp.properties"
"read")
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:372)
at
java.security.AccessController.checkPermission(AccessController.java:559)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.File.exists(File.java:808)
at
com.hp.hpl.jena.sparql.expr.NodeValue.getDatatypeFactory(NodeValue.java:211)
at com.hp.hpl.jena.sparql.expr.NodeValue.<clinit>(NodeValue.java:186)
Based on that it is clearly caused by a missing permission or privileged block.
In Stanbol I can fix this by adding such a privileged block over the
call to the Clerezza query engine, but this should clearly be fixed in
the actual implementation of Clerezza.
In Stanbol this is the actual cause for STANBOL-1188, but this might
also need an Issue for Clerezza.
best
Rupert
Jena version? (Just so line numbers line up - the code hasn't changed in
a while around here.)
It looks like JENA-328. https://issues.apache.org/jira/browse/JENA-328
NodeValue.getDatatypeFactory() has to go through hoops and maybe it's
not going through enough hoops or the right hooks.
https://svn.apache.org/repos/asf/jena/trunk/jena-arq/src/main/java/com/hp/hpl/jena/sparql/expr/NodeValue.java
Suggestions welcome - we seem to be at the point where what works for
one setup does not work for another - but is it a case of just
protecting the File.exists? Where is the DatatypeFactory supposed to
come from in the glassfish case?
Andy