Sakila: Sample app project setup

This sample application will integrate quite a few very nice open source tools available to every developer:

  • Postgresql – database
  • Flyway – database migration tool
  • Jooq – Java object oriented querying + HikariCP connection pool
  • Dagger 2 – dependency injection
  • SparkJava – fast and simple web server + GSON Json serializer
  • JavaScript Polymer SPA application framework
  • Vaadin Elements components

The application will consist of many modules :

Postgresql – database

Initialize sample database

For start we will install sample sakila database  in the local Postgresql database. Restore downloaded file into locally created database.

Sakila sample database is open source demo database and represent database model of DVD rental store. It  consist of  15 relational tables, 7 views and few other database details and it’s full of data.

Well that’s database with full of test data for development environment. If we need empty database (for production for example) we need to start initialization DDL script to build the database.

To create the script from the existing database use the command pg_dump which is capable of exporting database in the form of sql commands :

To export database without any data , only schema definitions we use “schema only” (-s) option.

Flyway migrations

Create flyway config file and “migrations” folder under the project root.

Add “fw” command somewhere on the path.

Put the “V1.0.1__sakila_init.sql” file in the migrations folder. If everything works as expected the “info” command should report the pending migration.

Flyway migration and initial database state after database restore

After restoring the database with test data in it we need to “baseline” initial migration. Initial sql script to create empty database was bypassed with restore. The V1.0.1__sakila_init.sql migration script was still pending.

With the baseline command we agree that the migration is not needed and you mark the migration version as migrated.


Setup java server project

In the IDE (IntelliJ IDEA Community 2017.2) create new console type project “sakilaweb/server”.

Setup git-bash terminal as default intellij terminal

Jooq – object oriented querying

Create jooq config file and add jooq command somewhere on the path.

Bash command:

Add “jooq-3.10.1.jar” library to project dependencies. Add “postgresql-42.1.4.jar” if you use the same database.

Run code generation tool with “jooq” command in the terminal at the project root.

After code was successfully generated in the “./database” folder you will get a bunch of database related code ready made ( database schema, POJOs, and DAOs).

The project with generated code will now look like :

Setup Dagger 2

Configure IDEA for annotations processor.

Add dagger dependencies (dagger-compiler only as “Provided” because it is used only for code generation ).

Setup SparkJava web server

Add few references to the project dependencies and setup “hello-world” web sample just to be sure everything is setup us expected before start real coding.

Create main procedure as :

Now if you run the application you should already get the first page:

Publish to the github

First enable VSC support in the local project and add .gitignore file to the project. Next we add files to the local git repository created in the project.

If we want  to push code to the remote repository we need to create it to have repository to commit to. Login to the github and create new empty repository.

The code for the server side project is available here.



Next : In the next installment I will put the generated database layer into the use and expose first REST service.






Dependency injection with Dagger 2

Prepare project to use dagger DI in IntelliJ IDE

The IntelliJ IDEA Community version 2017.2.5 is used in this example.

Open project structure and add dagger as project dependency from Maven repository.


The dagger compiler has to be available only for development phase (annotation processing will generate code) so we added it as “Provided” dependency.

Enable annotation processing in the project settings and select content root for generated code.

If you wish to inspect generated code in the project tree it is wise to open “generated” folder manually and mark it as “Source root”.  After compiling the project tree will look like this:

Create simple service application

First we will create very simple application without DI. The service application will consist of one Application class starting everything up and with single Service class doing some work.

Implement dagger dependency injection

To start as simple as possible we will not change how the application is instantiated and started.  The dagger is initialized in the Application object and the only injected instance will be the instance of Service class.

Now we need to create  “Module” object where we implement “provide” method to provide new instance of the service class. The module class must have @Module annotation and factory methods must have @Provides annotations.

Now we need a “Component” object which is an interface from which dagger generate injector class.  The component must contain a @Component annotation with defined modules and inject function signature.

The service class was not changed because we do not inject anything there, the service has no external requirements, so the code stay exactly the same as before:

Connect everything together

In the Application constructor we initialize the dagger with the build() and inject() functions. The injection is achieved with the @Inject annotation in front of the local “service” member declaration.

If a dagger want to inject a class member it must be publicly accessible because it is not using any reflection (that’s good for speed and debugging!). But we could also initialize private variables with the use of constructors marked with annotation @Inject taking in all required parameters.

Extending our knowledge

@Inject on the constructor instead of provide method

Now we could explain that provideXXX methods in the modules are not the only way how to explain to dagger how to construct the objects … We can instead of the method simpy annotate constructor of the object with @Inject.

Because only one constructor can have the @Inject annotation the dagger know exactly how the object should be constructed. The special provideXXX method on the module is not needed anymore.

Try to add constructor to Service class annotated with @Inject and delete provideService() method from the “SimpleModule” class , rebuild the project and everything should work as before. You can observer generated classes because know the daggergenerate special factory object with construction mechanism.

The code after changes should look like:

and the module:


More about the topic

DI and the dagger tool has many features not covered in this article. You can find more about them here .


Create an executable JAR from IntelliJ CE

To create executable JAR we need to create new artifact and build it. Build will save everything to the output folder.

The version of java used in the article was 1.8.

Automatically created build artifact:

  1. Open File/Project structure
  2. Create new artifact, JAR, from modules with dependencies:
  3. Enter proper startup class and select proper function how to use external 3rd party libraries in the target artifact (“copy to the output directory and link via manifest“). We don’t want to extract them to the target JAR file because some of them are probably signed and those will not work inside the target JAR. 

Now you can build artifact from the menu (/Build/Build artifact/) and test it from the command line:

Customized way of defining build artifact

If you wish to have more influence on target artifact then you use “Other” artifact type and design the process manually:

You can move external libraries into some sub folder for example and then create manifest file manually to reflect that new class path.

Sample manifest file:

If you edit MANIFEST.MF file just don’t forget to put two spaces between the jar files.

Read this blog for more detailed instructions..

Why we don’t create a single JAR from everything

Create one single JAR from everything the application consist is not a good idea because of security limitations. If any of 3rd party jar libraries is signed then the signature represent physical JAR file and when code is loaded from another  jar file (your single jar) the load mechanism will prevent loading because the signature doesn’t represent the jar file anymore.