Skip to Content
Author's profile photo Matthias Steiner

Getting started with Spring Boot – Part 2

Welcome back! In part 1 we discussed the basic concepts of Spring Boot and how-to create a configuration setup that allows to leverage all the nifty features (one word: livereloads) AND still support classic WAR deployments (as needed for SAP HANA Cloud Platform Tomcat 8 runtime.)

In this episode we’ll look into the topic of connecting to a database. Simple as it sounds, it gets a bit tricky if one considers the various scenarios that need to be supported:

  Stand-alone NEO (local) NEO (cloud) Cloud Foundry
Package type: JAR WAR WAR JAR
Datasource: manually defined provisioned via JNDI provisioned via JNDI auto-configuration
Profiles: dev neo neo cf

When running as stand-alone executable we need to manually define the properties to create a JDBC connection and instantiate a Datasource (see Connection to a production database).  The NEO runtimes automagically provision a reference to the configured Datasource via JNDI (see Retrieving Data Sources). Cloud Foundry makes it even simpler by using a concept known as auto-reconfiguration (see Auto-Reconfiguration) that will wire your DataSource automatically in case there’s only a single relational backing service bound to your app.



Arguably the easiest way to achieve this is by using so-called profiles and leverage profile-specific configurations. Let’s have a look at the respective config file:


Note: Admittedly, we could also have used the DataSourceAutoConfiguration feature that would create this by default if only one embedded database is found in the classpath (see Embedded Database Support), but for educational purposes we do take control of things, ok?

So, if we start the application using the ‘dev’ profile we’ll end up with a temporary embedded/in-memory Derby database:

mvn spring-boot:run -Drun.profiles=dev



As stated above, the Tomcat 8 runtime of SAP HANA Cloud Platform provisions a reference to the underlying Datasource via JNDI. That works the same way regardless of running it locally or in the cloud. Hence, we just need to define a Datasource factory bean that creates a respective Datasource via the JNDI lookup (see

public class NeoConfig 
	public DataSource jndiDataSource() throws IllegalArgumentException, NamingException
		JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup();
		DataSource ds = dataSourceLookup.getDataSource("java:comp/env/jdbc/DefaultDB");
		return ds;

NOTE: Please note that you need to specify the following JVM argument to make sure that Spring Boot runs in the ‘neo’ profile:


Cloud Foundry

As stated above it’s fairly simply to get the app to run on Cloud Foundry: all we need to ensure is that we bind a relational database backing service (e.g. Postgres) to the app. There are numerous ways to do this, but the most simple may be using a respective manifest:

- name: springboot-${random-word}
  memory: 512M
  instances: 1
  host: springboot
  path: target/ROOT.jar
    - postgres


Conclusion, final words and Outlook

As demonstrated it’s fairly easy to provide a Datasource for our app in such a way that it works in all scenarios using profiles. Still, we always need to indicate the profile to use, which does not really fly with the idea of (cloud agnostic) cloud-native apps, right?

So, in the next episode we’ll incorporate Spring Cloud Connectors… stay tuned!

Github repository

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Hey, please continue with the next episode 😉

      Author's profile photo Daniel Erdmann
      Daniel Erdmann

      I have absolutely no Idea what you did.