Skip to content

When developing any application, it’s quite common to have to access multiple databases. Out of the box, Spring Boot provides easy access to a single datasource, in the simplest case just by specifying the JDBC driver on the class path!

Accessing multiple databases however, is still straightforward with Spring Boot. This article shows how to connect to two different MySql datasources from a Spring Boot application.

To showcase how to connect to to different databases, consider a products database and a customer database, with the following simplistic schema and data.

Database One - Products Database

Schema - create table PRODUCT(id integer, name varchar(255));
Data - insert into PRODUCT(id, name) values (1, ‘XBox');

Database Two - Customer Database

Schema - create table CUSTOMER(`id` integer, `name` varchar(255));
Data - insert into CUSTOMER(id, name) values (1, 'Daphne Jefferson’);

To access the databases, we need to declare a JdbcTemplate for each database. In Spring, JdbcTemplates are created from a `DataSource` which has a set of connection properties (url, username, password etc.)

public class DataSourceConfig {

  DataSource customerDataSource() {
    return DataSourceBuilder.create().build();

  DataSource productDataSource() {
    return DataSourceBuilder.create().build();

  JdbcTemplate customerJdbcTemplate(@Qualifier("customerDataSource")DataSource 
customerDataSource) {
    return new JdbcTemplate(customerDataSource);

  JdbcTemplate productJdbcTemplate(@Qualifier("productDataSource")DataSource productDataSource) {
    return new JdbcTemplate(productDataSource);

In the above code we can see that a @Configuration bean has been declared that defines a customerDatasource and a customerJdbcTemplate. Each of these beans are annotated with the @Qualifier('customer...') to identify them as relating to the customer database.

Similarly, the above code defines a productDataSource and a productJdbcTemplate. Again these are annotated with @Qualifier('product...') to identify them as relating to the product database.

Finally, each DataSource Bean is annotated with the @ConfigurationProperties(prefix="...datasource") annotation. This tells Spring Boot what properties within the file should be used for connecting to each database. The file therefore looks like the following:

product.datasource.url = jdbc:mysql://localhost:3306/dbOne
product.datasource.username = user1
product.datasource.password = password
product.datasource.driverClassName = com.mysql.jdbc.Driver

customer.datasource.url = jdbc:mysql://localhost:3306/dbTwo
customer.datasource.username = user2
customer.datasource.password = password
customer.datasource.driverClassName = com.mysql.jdbc.Driver

Now that we've seen how to create a DataSource and JdbcTemplate, the JdbcTemplate can be injected into a @Repository for use, e.g.

public class CustomerRepository {

  private static final String SELECT_SQL = "select NAME from CUSTOMER where ID=?";

  JdbcTemplate customerJdbcTemplate;
  public String getCustomerName(int id) {
    String name = customerJdbcTemplate.queryForObject(SELECT_SQL, new Object[] {id}, String.class);

    return name;

Again, note the use of the @Qualifier annotation to specify which JdbcTemplate is required for the different repositories.

The ProductRepository is similarly written to access the productJdbcTemplate

public class ProductRepository {

  private static final String SELECT_SQL = "select NAME from PRODUCT where ID=?";

  JdbcTemplate productJdbcTemplate;
  public String getProductName(int id) {
    String name = productJdbcTemplate.queryForObject(SELECT_SQL, new Object[] {id}, String.class);

    return name;

With a few simple steps, Spring Boot allows us to easily connect to multiple databases when using JdbcTemplates.

The Eclipse MicroProfile version 1.1 has been released and builds upon the version 1.0 release by adding support for the Configuration API.

With the inclusion of the new Configuration API, Eclipse Microprofile, whose tag line is "Optimizing Enterprise Java for a microservices architecture", now supports the following APIs

  1. Configuration 1.0
  2. CDI 1.2
  3. JSON-P 1.0
  4. JAX-RS 2.0.1

The full specification for this release can be downloaded from here.

There is a vast amount of Developer Resources available around Eclipse MicroProfile including sample code and online resources available on the project's site. This is worth reading for those new to MicroProfile, as is the MicroProfile site at

The WildFly team have announced that WildFly 11 Beta 1 is now available. This release is now feature complete.

The key highlights of WildFly 11 Beta 1 are:

  • New Security Infrastructure - Elytron
  • Simplification of JNDI and EJB invocation
  • HTTP/2 support
  • Out of the box load balancer configuration

Of these changes, the most significant is the Elytron security system.

Elytron offers a centralised security framework that can be used both by applications deployed to the application server and by the application server itself, thus providing a consistent approach to security for WildFly 11 users. Elytron covers both authentication and authorization.

WildFly 11 Beta 1 can be downloaded directly from

What are your thoughts on this new Beta? How does it compare to previous version of WildFly that you've used? Get involved in the community and leave your thoughts below.

Running Payara Micro services on Heroku is incredibly straightforward.

There are 2 basic ways of running a Payara Micro service on Heroku:

  1. Create a Fat Jar
  2. Deploy a .War file along with PayaraMicro.jar

I prefer to deploy applications as .War files rather than Fat Jars, so in this example, I'll show how to create a Heroku application and deploy a Payara Micro service to it.

Enabling a Payara Micro Application For Heroku

To enable a Payara Micro application for running on Heroku, there are two simple steps we have to make. The first is to simply bundle the Payara Micro distribution file within the Maven project. (You could create a standalone app and completely use Maven, but I think this is a simpler solution). Download Payara Micro and place it in the \lib folder of the Maven project.

| |___payara-micro-
| |___main
| | |___java

The reason for deploying Payara Micro is simply that we need this to launch any service .War files. *Remember, we could use a Fat Jar, if that's your preference.*

Secondly, we need to create a file telling Heroku how to run the service that we are to deploy. This file, Procfile needs to be created at the root of the Maven project structure as shown above. The contents of this file tell Heroku how to start Payara Micro and deploy the application:

web:    java -jar lib/payara-micro- 
--deploy target/PayaraHeroku.war --port $PORT

There are a few things to say about the Procfile. You can see that this defines a web application that is invoked by java -jar lib/payara-micro- There are then a couple of Payara Micro command line options. --deploy tells Payara Micro to deploy the result of the Maven build (target/PayaraHeroku.war in this example). --port $PORT tells Payara Micro to listen on the correct port that Heroku is using

So that's it, there are only 2 small changes needed to a Payara Micro service to enable it to run on Heroku. We need to add the Payara Micro runtime and create a Procfile.

Deploying a Heroku Application

Once you've created a Payara Micro application, it needs to be deployed on Heroku. Deploying a Heroku application is documented in depth on the Heroku Dev Centre. You'll find everything you need to know about deploying Java applications there, so I'll only go over this briefly.

The basic steps are to:

  1. Create a Heroku Application heroku create
  2. Commit your Payara Micro service git add ... && git commit ...
  3. Push the git repository to Heroku git push heroku master
  4. Scale the application accordingly heroku ps:scale web=1

Once the git repository is pushed to Heroku, Heroku will work out that this is a Java application and will start the Maven build. This will create the artefact in the target directory on Heroku which is referenced by the Procfile. Once the build is complete, Heroku will start the Payara Micro service using the options defined within the Procfile.

And that's it! As you can see, there's very little you need to do to be able to get your Payara Micro services running on Heroku.

When deploying an application to Payara Micro, the default context path for any web resources is defined by the name of the archive.

For example, if I deploy the archive PayaraRest-1.0-SNAPSHOT.war, the context root is defined as /PayaraRest-1.0-SNAPSHOT

$ java -jar payara-micro.jar --deploy  PayaraRest-1.0-SNAPSHOT.war
[Payara Micro 4.1]  Loading application [PayaraRest-1.0-SNAPSHOT] at [/PayaraRest-1.0-SNAPSHOT]

There are a few techniques however for changing the context of deployed applications in Payara Micro.

File Name

The simplest way of changing the context of a deployed application is to change the name of the archive being deployed. The context will be set to the name of the archive, for example:

$ mv target/PayaraRest-1.0-SNAPSHOT.war target/Renamed.war

$ java -jar payara-micro.jar --deploy target\Renamed.war
[Payara Micro 4.1]  Loading application [Renamed] at [/Renamed]


The context of a web application can also be changed using the standard Payara configuration xml, by adding an entry into the glassfish-web.xml file within the project.

$ java -jar payara-micro.jar --deploy  PayaraRest-1.0-SNAPSHOT

Deploying via Code

Using Java code, it's relatively straightforward to deploy an application using a few lines of code. First of all, add the dependencies to Payara Micro into your pom.xml


Applications can then be deployed by creating an instance of a PayaraMicroRuntime and calling its deploy() method. This method takes the name and the context path to deploy:

package com.davidsalter.payaradeployer;

import fish.payara.micro.PayaraMicro;
import fish.payara.micro.PayaraMicroRuntime;

public class Main {

        PayaraMicroRuntime instance = PayaraMicro.bootstrap();
        InputStream is = new FileInputStream("<path to>\PayaraRest-1.0-SNAPSHOT.war");
        instance.deploy("PayaraRest", "Programatically", is);
[Payara 4.1] Loading application [PayaraRest] at [/Programatically]

/ Deployments

One final point to note is that if you wish to deploy an application at the root context /, this can be achieved by renaming the deployment ROOT.war

$ mv target/PayaraRest-1.0-SNAPSHOT.war target/ROOT.war

$ java -jar payara-micro.jar --deploy target\ROOT.war
[Payara Micro 4.1] Loading application [ROOT] at [/]


In this article, I've shown a few different techniques for changing the deployment context for web applications in Payara Micro. Hopefully you'll agree that these simple techniques can allow you to make useful changes to your microservice deployments.