Null Pointer Exception with Stardog 4.2.1 and the Stardog Spring 4.1 libraries

4 views
Skip to first unread message

Andrea Westerinen

unread,
Dec 13, 2016, 7:14:23 PM12/13/16
to Stardog
When executing a query with a Spring RowMapper, the code successfully enters the SnarlTemplate query call, gets a connection, executes the query and gets a result (through line 388 in SnarlTemplate.java).  But, in the iterator loop starting at line 388 in SnarlTemplate, a null pointer is encountered.  Actually, the null pointer happens at line 389 ...

   list.add(mapper.mapRow(result.next()));

Please let me know what to change to address this.  I am running gradle 3.2.1, spring-boot-gradle 1.4.2, spring 4.3.4, stardog 4.2.1 and stardog spring 4.1 (the latest available on github).

Thanks.
Andrea


 


Al Baker

unread,
Dec 13, 2016, 7:37:59 PM12/13/16
to sta...@clarkparsia.com
Hi Andrea,

How are you passing in the RowMapper?  Typically it would be an anonymous argument on the query method, for example:

		String sparql = "SELECT ?a ?b WHERE { ?a  <http://purl.org/dc/elements/1.1/title> ?b } LIMIT 5";
		
		List<Map<String,String>> results = tmp.query(sparql, new RowMapper<Map<String,String>>() {

			@Override
			public Map<String,String> mapRow(BindingSet bindingSet) {
				Map<String,String> map = new HashMap<String,String>();
				map.put("a", bindingSet.getValue("a").stringValue());
				map.put("b", bindingSet.getValue("b").stringValue());
				return map;
			} 
			
		});

Or you can implement the interface and re-use them.  There is a SimpleRowMapper for Map<String,String> mappings available in the mapper package.

There are examples of various RowMapper usages here:


Thanks,
Al


--
-- --
You received this message because you are subscribed to the C&P "Stardog" group.
To post to this group, send email to sta...@clarkparsia.com
To unsubscribe from this group, send email to
stardog+u...@clarkparsia.com
For more options, visit this group at
http://groups.google.com/a/clarkparsia.com/group/stardog?hl=en

Andrea Westerinen

unread,
Dec 13, 2016, 8:08:31 PM12/13/16
to Stardog
Al, I narrowed the error down to having OPTIONAL clauses in the query ... and having NO values for at least one of the optional variables.

When I run the query from the command line or from the admin console, I get a result for the query (but obviously no value for the missing/optional variables).  When I use the Spring mapper, I always get a null pointer.  If I have no optional and missing variables, then the query and mapper work as expected.

Andrea

Andrea Westerinen

unread,
Dec 14, 2016, 4:32:16 PM12/14/16
to Stardog
Al, Another update ... the OPTIONAL thing was a fluke, not the real problem.  (But it seemed reasonable late last night :-)

Anyway, after more investigation and tinkering around, the issue is that I have a RowMapper defined in one DAO/ "@Repository" that is referenced by 3 other DAOs. This setup worked in the past, but no longer.  Now, I have to either:
  • Separately annotate the RowMapper in the single DAO with its own @AutoWired, which has ripple effects in the Snarl Spring implementation (i.e., the Snarl Spring, generic RowMapper also would have to be @AutoWired)
  • Change the code to not reference the RowMapper in the single DAO but jump into a "query" function which then executes the query and references the (internal) RowMapper
Obviously, the second is the easier and cleaner way of handling this.

But, in debugging the code, I found that the Spring files need to be updated with all the changes defined in the migration guide for Stardog 4.2.1.  The code still references URI (versus IRI), it uses deprecated imports from openrdf, etc.

Posting this here just in case anyone might have done the same thing as I (referenced a RowMapper across DAOs without AutoWiring it).


---
You received this message because you are subscribed to the Google Groups "Stardog" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stardog+unsubscribe@clarkparsia.com.

Al Baker

unread,
Dec 15, 2016, 9:48:29 AM12/15/16
to Stardog
Thanks Andrea - I'll make a note in the docs about RowMapper wiring.  I'll also release an updated version of stardog-spring with migrations for the deprecated packages.

Al


On Wednesday, December 14, 2016 at 4:32:16 PM UTC-5, Andrea Westerinen wrote:
Al, Another update ... the OPTIONAL thing was a fluke, not the real problem.  (But it seemed reasonable late last night :-)

Anyway, after more investigation and tinkering around, the issue is that I have a RowMapper defined in one DAO/ "@Repository" that is referenced by 3 other DAOs. This setup worked in the past, but no longer.  Now, I have to either:
  • Separately annotate the RowMapper in the single DAO with its own @AutoWired, which has ripple effects in the Snarl Spring implementation (i.e., the Snarl Spring, generic RowMapper also would have to be @AutoWired)
  • Change the code to not reference the RowMapper in the single DAO but jump into a "query" function which then executes the query and references the (internal) RowMapper
Obviously, the second is the easier and cleaner way of handling this.

But, in debugging the code, I found that the Spring files need to be updated with all the changes defined in the migration guide for Stardog 4.2.1.  The code still references URI (versus IRI), it uses deprecated imports from openrdf, etc.

Posting this here just in case anyone might have done the same thing as I (referenced a RowMapper across DAOs without AutoWiring it).

Al Baker

unread,
Dec 21, 2016, 7:59:48 AM12/21/16
to Stardog
Andrea,

I released 4.2.1 for stardog-spring, stardog-spring-batch, and stardog-groovy  jars on Maven central last night.  Can you give stardog-spring a try and note any issues back?

Thanks,
Al
Reply all
Reply to author
Forward
0 new messages