Enterprise Java

Configure JBoss / Wildfly Datasource with Maven

Most Java EE applications use database access in their business logic, so developers are often faced with the need to configure drivers and database connection properties in the application server. In this post, we are going to automate that task for JBoss / Wildfly and a Postgre database using Maven. The work is based on my World of Warcraft Auctions Batch application from the previous post.
 
 
 
 
 
 

Maven Configuration

Let’s start by adding the following to our pom.xml:

Wildfly Maven Plugin


    org.wildfly.plugins
    wildfly-maven-plugin
    1.0.2.Final
    
        
            false
            
            
        
    
    
        
            org.postgresql
            postgresql
            9.3-1102-jdbc41
        
    

We are going to use the Wildfly Maven Plugin to execute scripts with commands in the application server. Note that we also added a dependency to the Postgre driver. This is for Maven to download the dependency, because we are going to need it later to add it to the server. There is also a ${cli.file} property that is going to be assigned to a profile. This is to indicate which script we want to execute.

Let’s also add the following to the pom.xml:

Maven Resources Plugin


    org.apache.maven.plugins
    maven-resources-plugin
    2.6
    
        
            copy-resources
            process-resources
            
                copy-resources
            
            
                ${basedir}/target/scripts
                
                    
                        src/main/resources/scripts
                        true
                    
                
                
                    ${basedir}/src/main/resources/configuration.properties
                
            
        
    

With the Resources Maven Plugin we are going to filter the script files contained in the src/main/resources/scripts and replace them with the properties contained in ${basedir}/src/main/resources/configuration.properties file.

Finally lets add a few Maven profiles to the pom.xml, with the scripts that we want to run:

Maven Profiles


    
        install-driver
        
            wildfly-install-postgre-driver.cli
        
    

    
        remove-driver
        
            wildfly-remove-postgre-driver.cli
        
    

    
        install-wow-auctions
        
            wow-auctions-install.cli
        
    

    
        remove-wow-auctions
        
            wow-auctions-remove.cli
        
    

Wildfly Script Files

Add Driver

The scripts with the commands to add a Driver:

wildfly-install-postgre-driver.cli

# Connect to Wildfly instance
connect

# Create Oracle JDBC Driver Module
# If the module already exists, Wildfly will output a message saying that the module already exists and the script exits.
module add \
    --name=org.postgre \
    --resources=${settings.localRepository}/org/postgresql/postgresql/9.3-1102-jdbc41/postgresql-9.3-1102-jdbc41.jar \
    --dependencies=javax.api,javax.transaction.api

# Add Driver Properties
/subsystem=datasources/jdbc-driver=postgre: \
    add( \
        driver-name="postgre", \
        driver-module-name="org.postgre")

Database drivers are added to Wildfly as a module. In this was, the driver is widely available to all the applications deployed in the server. With ${settings.localRepository} we are pointing into the database driver jar downloaded to your local Maven repository. Remember the dependency that we added into the Wildfly Maven Plugin? It’s to download the driver when you run the plugin and add it to the server. Now, to run the script we execute (you need to have the application server running):

mvn process-resources wildfly:execute-commands -P "install-driver"

The process-resources lifecycle is needed to replace the properties in the script file. In my case ${settings.localRepository} is replaced by /Users/radcortez/.m3/repository/. Check the target/scripts folder. After running the command, you should see the following output in the Maven log:

 {"outcome" => "success"}

And on the server:

INFO  [org.jboss.as.connector.subsystems.datasources] (management-handler-thread - 4) JBAS010404: Deploying non-JDBC-compliant driver class org.postgresql.Driver (version 9.3)
INFO  [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-4) JBAS010417: Started Driver service with driver-name = postgre

wildfly-remove-postgre-driver.cli

# Connect to Wildfly instance
connect

if (outcome == success) of /subsystem=datasources/jdbc-driver=postgre:read-attribute(name=driver-name)

    # Remove Driver
    /subsystem=datasources/jdbc-driver=postgre:remove

end-if

# Remove Oracle JDBC Driver Module
module remove --name=org.postgre

This script is to remove the driver from the application server. Execute mvn wildfly:execute-commands -P "remove-driver". You don’t need process-resources if you already executed the command before, unless you change the scripts.

Add Datasource

wow-auctions-install.cli

The scripts with the commands to add a Datasource:

wow-auctions-install.cli

# Connect to Wildfly instance
connect

# Create Datasource
/subsystem=datasources/data-source=WowAuctionsDS: \
    add( \
    	jndi-name="${datasource.jndi}", \
    	driver-name=postgre, \
    	connection-url="${datasource.connection}", \
    	user-name="${datasource.user}", \
    	password="${datasource.password}")

/subsystem=ee/service=default-bindings:write-attribute(name="datasource", value="${datasource.jndi}")

We also need a a file to define the properties:

configuration.properties

datasource.jndi=java:/datasources/WowAuctionsDS
datasource.connection=jdbc:postgresql://localhost:5432/wowauctions
datasource.user=wowauctions
datasource.password=wowauctions

Default Java EE 7 Datasource

Java EE 7, specifies that the container should provide a default Datasource. Instead of defining a Datasource with the JNDI name java:/datasources/WowAuctionsDS in the application, we are going to point our newly created datasource to the default one with /subsystem=ee/service=default-bindings:write-attribute(name="datasource", value="${datasource.jndi}"). In this way, we don’t need to change anything in the application. Execute the script with mvn wildfly:execute-commands -P "install-wow-auctions". You should get the following Maven output:

org.jboss.as.cli.impl.CommandContextImpl printLine
INFO: {"outcome" => "success"}
{"outcome" => "success"}
org.jboss.as.cli.impl.CommandContextImpl printLine
INFO: {"outcome" => "success"}
{"outcome" => "success"}

And on the server:

INFO  [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-1) JBAS010400: Bound data source 

wow-auctions-remove.cli

# Connect to Wildfly instance
connect

# Remove Datasources
/subsystem=datasources/data-source=WowAuctionsDS:remove

/subsystem=ee/service=default-bindings:write-attribute(name="datasource", value="java:jboss/datasources/ExampleDS")

This is the script to remove the Datasource and revert the Java EE 7 default Datasource. Run it by executing mvn wildfly:execute-commands -P "remove-wow-auctions"

Conclusion

This post demonstrated how to automate add / remove Drivers to Wildfly instances and also add / remove Datasources. This is useful if you want to switch between databases or if you’re configuring a server from the ground up. Think about CI environments. These scripts are also easily adjustable to other drivers.

Enjoy!

Roberto Cortez

My name is Roberto Cortez and I was born in Venezuela, but I have spent most of my life in Coimbra – Portugal, where I currently live. I am a professional Java Developer working in the software development industry, with more than 8 years of experience in business areas like Finance, Insurance and Government. I work with many Java based technologies like JavaEE, Spring, Hibernate, GWT, JBoss AS and Maven just to name a few, always relying on my favorite IDE: IntelliJ IDEA.Most recently, I became a Freelancer / Independent Contractor. My new position is making me travel around the world (an old dream) to customers, but also to attend Java conferences. The direct contact with the Java community made me want to become an active member in the community itself. For that reason, I have created the Coimbra Java User Group, started to contribute to Open Source on Github and launched my own blog (www.radcortez.com), so I can share some of the knowledge that I gained over the years.
Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button