Browsed by
Tag: wildfly

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