I am using Jena API. Every thing works fine with me, except when query match (i.e. result of Query is null) is not found in an Ontology Model. Then nothing is displayed in Browser using servlet, and null pointer exception is displayed at console. i.e given below. Can anyone guide me how to handle this null pointer exception? thank you.

Jun 04, 2014 3:37:22 PM org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet [main.DevInsta] in context with path [/FMOnt] threw exception
    at main.DevInsta.doGet(DevInsta.java:71)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:621)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:728)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:409)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1044)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:607)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:313)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    at java.lang.Thread.run(Unknown Source)
  • 1
    Two additional things will assist greatly in answering this question: (1) The query that is failing (2) The code that is invoking the query (especially at/around line 71). As you allude to in your question, the exception isn't happening in Jena's code (it bottoms out in your DevInsta.doGet method), so there is some mismanagement of results. We can only give vague/general solutions if we don't have the additional context. – Rob Hall Jun 4 '14 at 14:52

Initial Solution

At the time of this answer, the query string used in this question is not posted, nor is the code which is used around where the NullPointerException occurs. This is a first-pass at assisting with the answer.

My usual source of a NullPointerException when working with a QueryExecution comes from one of two places:


If your query is using GROUP BY x, but your data doesn't bind anything to x, you can end up with a ResultSet that looks like the following:

|  ?x  |  ?y  |
|      |      |

You can get an unexpected true result from hasNext(), and then a subsequent NullPointerException when attempting to retrieve elements. The solution is, for aggregate queries, to test if the first result's expected bindings contain any null values as well.


If your query includes an optional block, then it may not get bound for a particular solution, and you need to test for it:

SELECT ?x ?y {
   ?x rdf:type urn:ExampleClass .
   OPTIONAL { ?x urn:p ?y }

When you iterate over QuerySolution objects, the value returned by getting a variable may be null, and you need to account for it in your code.

WebService Help

One thing which I would suggest, if your ResultSet isn't very large, is to use a ResultSetRewindable (provided by ResultSetFactory.copyResults). In your web application, if you use a decent logging library, you can test things like logger.isDebugEnabled(). If it is, you can print a diagnostic value for the query using ResultSetFormatter. This can be extremely useful when attempting to understand why your rendering of a query is giving you unexpected results:

final QueryExecution exec = ...;
final ResultSetRewindable r = ResultSetFactory.copyResults(exec.execSelect());
// Assuming slf4j
if( logger.isDebugEnabled() ) {
    final ByteArrayOutputStream results = new ByteArrayOutputStream();
    logger.debug("Rendering query solution:\n{}", results);
// Continue on like you normally would 

If you don't want to do this in general (maybe doGet is called far too often and/or your results are too large and/or this is a complex system where the error happens rarely), then you can always put a try{..}catch(..){..}-block around where the exception is occurring, and only print a copy of the results when this particular exception is triggered.

Your Answer

