Dynamic switching dev and prod datasource with maven profiles

Dynamic switching dev and prod datasource with maven profiles

maven logo
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

<subsystem xmlns="urn:jboss:domain:datasources:4.0">
  <datasources>
    <datasource jndi-name="java:jboss/datasources/ExampleDS" pool-name="ExampleDS" enabled="true" use-java-context="true">
      <connection-url>jdbc:h2:mem:test;DB_CLOSE_DELAY=-1;DB_CLOSE_ON_EXIT=FALSE</connection-url>
        <driver>h2</driver>
        <security>
          <user-name>sa</user-name>
        </security>
      </datasource>

      <datasource jndi-name="java:jboss/datasources/ExampleMySQLDS" pool-name="ExampleMySQLDS" enabled="true" use-java-context="true">
        <connection-url>jdbc:mysql://localhost:3306/brachub</connection-url>
        <driver>mysql</driver>
        <security>
            <user-name>root</user-name>
            <password>1234</password>
        </security>
        <statement>
            <prepared-statement-cache-size>100</prepared-statement-cache-size>
            <share-prepared-statements>true</share-prepared-statements>
        </statement>
    </datasource>

    <drivers>
      <driver name="h2" module="com.h2database.h2">
        <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>
      </driver>
      <driver name="mysql" module="com.sql.mysql">
        <driver-class>com.mysql.jdbc.Driver</driver-class>
      </driver>
    </drivers>
  </datasources>
</subsystem>

Read More Read More

Apache Shiro part 2 – securing a JSF Java EE 7 application

Apache Shiro part 2 – securing a JSF Java EE 7 application

apache shiro logo

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

the pom file.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>de.are_you_ready</groupId>
    <artifactId>shirotest</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>

    <properties>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <failOnMissingWebXml>false</failOnMissingWebXml>

        <apache-shiro.version>1.3.2</apache-shiro.version>
        <primefaces.version>6.0</primefaces.version>
        <junit.version>4.12</junit.version>
    </properties>

    <dependencies>
        <dependency>
            <groupId>javax</groupId>
            <artifactId>javaee-api</artifactId>
            <version>7.0</version>
            <scope>provided</scope>
        </dependency>

        <!-- Security -->
        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-core</artifactId>
            <version>${apache-shiro.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-web</artifactId>
            <version>${apache-shiro.version}</version>
        </dependency>

        <dependency>
            <groupId>org.apache.shiro</groupId>
            <artifactId>shiro-ehcache</artifactId>
            <version>${apache-shiro.version}</version>
        </dependency>

        <!-- PrimeFaces -->
        <dependency>
            <groupId>org.primefaces</groupId>
            <artifactId>primefaces</artifactId>
            <version>${primefaces.version}</version>
        </dependency>

        <!-- Testing -->
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <version>${junit.version}</version>
            <scope>test</scope>
        </dependency>

        <!-- Logging -->
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.17</version>
        </dependency>
    </dependencies>

    <build>
        <finalName>shirotest</finalName>
    </build>
</project>

Read More Read More

Apache Shiro part 1 – selecting a Java security framework

Apache Shiro part 1 – selecting a Java security framework

apache sharp logo
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 Read More

Don’t rely on Java finalizers

Don’t rely on Java finalizers

java-logo
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
[java]
protected void finalize() {
logger.info(“start important work before GC”);
fooBar.persist(this.getDataMap());
}
[/java]

Read More Read More

Find and kill a process on a specific port (lsof)

Find and kill a process on a specific port (lsof)

terminal-app
You might all have experienced the situation when you want to start a server either from within your IDE or via the terminal to only get the error that the “port is already in use” and the startup is aborted. This is mostly caused by aborting the server or a crash of the IDE which started it and not terminating it properly. When using macOS (or any other BSD or a Linux) there is a simple solution for this.

For such purposes macOS comes with the “lsof” command which stands for “list open files”. Its purpose is to show who is using a specific file or in our case who is using a specific port. After identifying the process it is easy to terminate it using the “kill” command.

Read More Read More