Part 7a – Configuring Crawl4Neo

Let’s get some boilerplate work out of the way.  These steps are necessary for a real Spring application.  Fortunately, once this is complete we won’t have to visit this stuff very often.

Packages

This package structure is a little closer to what I would use for a commercial project.  Since, our project has taken a big leap forward in complexity now it a good time to start organizing our code.

packages1

 config

Configuration information, while minimal with Spring Boot, is still necessary.  To me it’s just the dirty facts of life and I like to keep it separate from the ‘real’ code.  If we were to grow this into a full, commercial web application, then there would be quite a bit of configuration.  It’s just a good habit to keep a config package to hold it all.

data

This is where we’ll place all the entities we are going to keep in Neo4J.  I put the repositories in this package as well for this project.  This might change overtime, but it’s clean.

services

These are the workhorse classes, where stuff really happens.  When a class is configured as a Spring Service, it’s best practice to suffix the name with ‘Service’.  These are beans we can ‘autowire’ into our application as needed.

Configuration

pom.xml

Lines 11-15 allow us to pull dependency information directly from Spring.  They have gone to the work of identifying which versions of what jars play nicely together.  Frankly, this parent pom is what makes Spring Boot so attractive.

Lines 31-34 install the Spring Boot plug in.  It will help us compile and run our application with minimal effort.

Lines 72-83 list the Spring Framework modules we want in our project.  For our purposes we only need to list Spring Boot and Spring Data Neo4j.  Spring Boot looks at those jars and figures out what sort of application we are building.  It then brings in other jars as needed and wires up a default configuration.

CrawlerConfig.java

@Configuration tells Spring that this file provides configuration information to the system.

@EnableNeo4jRepositories does just was it says.  We need to include a basePackageClasses option so Spring will scan for relevant classes.  If you leave out basePackageClasses you’ll get the message:

Basically, Spring won’t see that we have things like Repository beans.  So when it tries to wire up our Service that uses the repository, it can’t resolve the dependency.

Alternatively, you could code it this way:

I found using ‘basePackages’ is error prone.  Specifying the package as text means you won’t get a compile error when you refactor your code (which I do relentlessly).  ‘basePackageClasses’ simply uses the class you specify to find the base package to start scanning.  BTW, I just use a class at the highest level and be done with it.  Why specify several package names only to forget one?  After all, package scanning only happens at boot time.

Line 16 is an anomaly that the Spring Data Neo4j team got rid of in Version 4.  I’m not sure why they required it, but if you leave it out you’ll get this exception when you try to save any data:

(We’ll convert our project to version 4 after I understand it better.)

Line 21 is where we give our database a file name.  Everything Neo4j needs to save goes in one file – I love it.

This covers our configuration stage.  We can now move on to the application.