clerezza-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy Seaborne <a...@apache.org>
Subject Re: Clerezza/Jena SPARQL initialization fails due to a SecurityException
Date Tue, 17 Dec 2013 10:14:40 GMT
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

Mime
View raw message