a blog by Sebastian Basner

Flyway is my favourite tool when it comes to database migrations because its convention over configuration approach makes it fairly easy to use while bootstrapping and configuration is reduced to a minimum. For those of you who don’t know anything about database migration tools (evolutionary database design) in short the concept is to track SQL scripts with your source code which reflect the actual version of your database that matches the code version to run properly. This could be done without any framework but what tools like Flyway or liquibase bring to the table is the ability to check automatically at build- or start-time if the database is at the latest available version and if not run all available SQL scripts from the actual database version to the newest one available. Flyway can be used with all the major SQL dialects, many different relational databases and has plugins for a huge variety of frameworks to be integrated into. For more detailed information visit the projects website.

As I’m a heavy Java EE user I ran into the problem that Java EE has no special support by Flyway. My problems with this are that there is no build in way to get the actual JPA datasource (defined in the persistence.xml) and there is no solution provided that wires Flyway in the startup process to run the migration scripts at startup. Flyway provides integration plugins with this functionalities for other frameworks like Spring Boot but fortunately it is not that complicated to realise the same thing in Java EE.

In many scenarios it is no problem to trigger Flyway in the right moment as it is possible to integrate it in the maven build process or start it manually via the command line but both solutions doesn’t fit my needs. I want to have Flyway check my database at startup as the production server is not the server where the build process happens and I want to avoid a situation where I have to execute a shell command manually after deploying a new version. For this cases Flyway can be started from the source code as well. As it has to be run before the application starts and tries using the database you have to make sure that the Flyway scripts are run before that. I found two solutions to make this work. The first one uses Hibernates “Service Provider Interface” (SPI) -I use WildFly in this example which comes with Hibernate- to register a new integrator and grab the datasource via a little bit of reflection code while the second approach (which is my favourited solution) defines a new singleton bean which uses @resource injection to get the datasource.

Most of the time when you develop an application that uses a database you are likely to use another database for your local development work than what you will use later in production. The main reason for this is that there are databases like H2 which by design are fitting the development situation while they are not very well suited for production usage. H2 i.e. has very fast startup times, can run completely in memory -this is an advantage because every time it is restarted its state is reset, too-, uses only few system resources and has a good mySQL compatibility. On the other hand it is not that popular in production as it lacks many functionalities like custom functions, an SQL interpreter etc.. Following this it is a very common scenario to use mySQL in production while using H2 for development. This way the developer can use the same database dialect for development while the local installation of a mySQL DB is not needed.
The problem with this scenario is that you need to switch the datasource to production when you build a new release and switch back to development when you want to use your local H2 for testing. This is something which can easily be forgotten and become annoying over time. Therefore it is a step which could and should be automated.
When you are using JavaEE you define your datasource depending on the application server either via an interactive tool (i.e. glassfish or payara via the asadmin command) or in a xml file (i.e. wildfly/jboss standalone.xml or TomEE context.xml). As an example I show you here a valid datasource definition in the wildly standalone.xml

In the first part I described why I chose Apache Shiro as an Authentication framework. In this part I will describe the simplest working solution to secure a Java EE7 application with JSF/Primefaces frontend. To be honest I wont use much of Primefaces in this sample but the application for which I did this research uses it so I added the dependency here and added an Primefaces component to this demo project.

Bootstrapping

I created an empty Java EE project via maven and added the needed Shiro dependencies as well as the Primefaces dependency to

What is Shiro?Apache Shiro is an open source Java security framework which makes authentication, authorization and cryptography very easy to use with a simple and small configuration. It is very portable because of its independence from the used application frameworks and covers all kinds of scenarios from console over desktop client to web applications.

Why Shiro?
I searched for a security solution (authorization and authentication) which I plan to reuse in multiple “pet projects” without having to think about the same problem over and over again. My actual project is a web project based on Java EE 7 and has at the moment a JSF/Primefaces frontend. I plan to extend the application with a REST interface and an alternative UI technology for personal testing/learning and research purposes. Maybe there will also be an iOS app later on which should use the then existent REST endpoint. With that in mind I need a flexible framework to support securing JAX-RS endpoints as well as my actual JSF UI.
I previously had some experience with the Java EE standard solution JAAS as well as the JBoss project Picketlink. Additional to that I’ve worked in projects using Spring Security (but had not much to do with it) which seems to be the industry standard nowadays but besides that I did a little research about possible alternatives I wasn’t aware of and came up with Apache Shiro and Keycloak.
This four/five tools and frameworks were the solutions I considered and researched which would be the best fit for me. Read More »

Recently I was facing a problem where a Java application should persist a part of its state when it was closed. This was already implemented but seemed to work just unreliably and it was not clearly reproducible when it worked properly and when it failed. After analyzing the existing source code I figured out that finalizers were used to implement the functionality by delegating the call of the persist logic to the garbage collector. This seems like a very good idea at first but lacks in reliability. As a short note up front don’t use finalizers for important things.

A finalizer is a method which represents the opposite of a constructor. It is a method with the purpose to do some cleanup work, free up some memory and so on which gets called by the garbage collector before the object gets collected. A simple example would look like this