Cloud Zone is brought to you in partnership with:

As VP of Technology Evangelism at WSO2, Chris Haddad raises awareness of Platform as a Service, Cloud Architecture, Service Oriented Architecture, API Management, and Enterprise Integration. Prior to joining WSO2, Haddad’s experience includes building software development teams, contributing to open source, crafting technology roadmaps, leading Gartner research teams, and delivering Software as a Service and Web applications. Chris is a DZone MVB and is not an employee of DZone and has posted 107 posts at DZone. You can read more from them at their website. View Full User Profile

How to Deploy Spring Database Apps to CloudFoundry

07.10.2012
| 5350 views |
  • submit to reddit
Posted on April 21, 2011

Deploying Spring applications to CloudFoundry.com really is as easy as SpringSource say it is.

After being approved for a Cloud Foundry beta account, the first stage is to install Cloud Foundry support into STS or Eclipse. Christian Dupuis has an excellent blog post on how to achieve this, so I won’t re-iterate what he has already said.

To deploy and run an application using a datasource, MySQL in my case, requires a bit more effort than deploying a standalone application, but literally very little.
To deploy an application with a datasource, you must first declare which datasource to use.  In Eclipse, open up the Cloud Foundry server and press the “Add” button on the services pane.

On the following screen, select a name and type for the datasource.
Press the “Finish” button and the datasource is registered.

After registering a datasource, you need to tell the application which datasource to use.  This is as straightforward as dragging the datasource onto the “Application  Services” panel for the Cloud Foundry server.

That’s all the configuration that is needed for the server. Before deploying an application though, a couple of changes are needed to specify which datasource is required.

Because I’m deploying a Spring application, I need to change the application context file to point to the new Cloud Foundry database rather than a local database.  The nice thing about using a Cloud Foundry database is that database credentials are not needed, all that is needed is to change the datasource bean configuration in the servlet-context.xml file.

For a local deployment, a datasource configuration would look something like:

<bean id="dataSource"
 class="org.springframework.jdbc.datasource.DriverManagerDataSource" 
 p:driverClassName="${jdbc.driverClassName}"
 p:url="${jdbc.url}" />

To configure this to use a Cloud Foundry MySQL database, the datasource configuration would look like:

<cloud:data-source id="dataSource" />

Spring 3.1 contains a new profiles feature to allow both of these configurations to be stored within the same context file. On Spring 3 however this feature is not available so the context file needs to either contain the regular bean dataSource definition or the new cloud data-source definition.

To access the new cloud tag, the servlet-context.xml needs changing to access the cloud namespace.

<beans xmlns="http://www.springframework.org/schema/beans"
  ...  xmlns:cloud="http://schema.cloudfoundry.org/spring"
  ...  http://schema.cloudfoundry.org/spring
    http://schema.cloudfoundry.org/spring/cloudfoundry-spring-0.6.xsd">

To deploy the application, one final change is needed to add Cloud Foundry support. This is achieved by adding a dependency to Cloud Foundry in the applications pom.xml file.

<!-- CloudFoundry -->
<dependency>
  <groupId>org.cloudfoundry</groupId>
  <artifactId>cloudfoundry-runtime</artifactId>
  <version>${org.cloudfoundry-version}</version>
</dependency>
<properties>
  <org.cloudfoundry-version>0.6.0</org.cloudfoundry-version>
</properties>

After making these changes, the Cloud Foundry application can be deployed and started and stopped using the controls within STS.

 

 

 

 

 

Published at DZone with permission of Chris Haddad, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)