NoSQL Zone is brought to you in partnership with:

I'm the CIO of a small software/tech consulting firm in Toronto, Canada. NoSQL is a passion of mine, especially graph-based databases! Also love tech and software in general, and am always looking how to take something cool and apply it to something that has a business case or solves a problem. Thanks for reading! Duncan is a DZone MVB and is not an employee of DZone and has posted 10 posts at DZone. You can read more from them at their website. View Full User Profile

Upgrading Spring Data Neo4j and Neo4j: "Gotchas" to Watch for

12.27.2013
| 8994 views |
  • submit to reddit

I'm back with a quick post (with more to come soon).

I was in the middle of upgrading my little test project to a newer version of Spring Data Neo4j and Neo4j itself when I came across a few little points that others might find useful (though it should be noted that Neo4j is set to release 2.0 very soon and is currently doing milestone releases).

I upgraded SDN to 2.3.1.RELEASE and Neo4j (all aspects of it, including Cypher) to 1.9.4.
Here are a couple "gotchas" I encountered:

Dependencies

It would seem that CGLIB has been moved out of one of the Neo4j or SDN dependencies; however, I also found that--with the SDN/Neo4j combination I'm using--that a specific version is required, namely 2.2.2. Adding this bit into my POM fixed things up nicely:
<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>2.2.2</version>
</dependency>

No Bean Named 'graphDatabaseService' is Defined

This one was fun.  As confirmed in this Neo4j forum thread (which actually uses Neo4j 1.7 and SDN 2.1.0.Build-Snapshot), when configuring Neo4j in an application context, the bean ID for the graph database service (whether it's embedded or from a server) must be "graphDatabaseService", similar to this:
<bean id="graphDatabaseService"
  class="org.springframework.data.neo4j.rest.SpringRestGraphDatabase">
  <constructor-arg index="0" value="http://someserver:7474/db/data" />
</bean>
If this little nuance is overlooked, you could very well see exceptions when, say, starting up your application server with your SDN-based application. In my case, Maven compiled my WAR file just fine, but, starting up Tomcat produced a slew of exceptions. It would seem that this is an ongoing issue, though, perhaps it's a necessary change from the SDN folks.  We'll just have to see! Hopefully some people find these tidbits useful. We'll see you on the next post!
Published at DZone with permission of Duncan Brown, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)