Skip to content
This repository has been archived by the owner on Nov 4, 2024. It is now read-only.

Latest commit

 

History

History
84 lines (66 loc) · 3.85 KB

File metadata and controls

84 lines (66 loc) · 3.85 KB

Binding PostgreSQL instances to Liberty applications

If you bind a PostgreSQL service instance to an application, the Liberty buildpack also generates the following configuration elements in the server.xml file. The configuration elements are required to access the PostgreSQL database.

  • A dataSource element with a default properties subelement.
  • A jdbcDriver element.
  • A library element with an embedded fileset subelement. The library element is created for the Java Database Connectivity (JDBC) driver.
  • A featureManager element. The Liberty buildpack also adds the jdbc-4.0 feature to the featureManager element.

In addition, the Liberty buildpack provides the JDBC driver that is required.

In the dataSource element, the Liberty buildpack generates a JNDI name that is used by your application to access the data source. Because the Liberty buildpack does not have access to the JNDI name that is used by the application, the Liberty buildpack generates a JNDI name with a convention of jdbc/service_name, where service_name is the name of the bound service. For example, if you bind a PostgreSQL service instance that is named mydb to the application, the Liberty buildpack generates a JNDI name of jdbc/mydb. When you develop the application and create the PostgreSQL service instance, ensure that the JNDI name that is used by the application to access the data source is the same as the JNDI name that is generated by the Liberty buildpack.

The following example shows the configuration that is generated when an application is pushed to the cloud and is bound to a PostgreSQL service that is named mydb:

<dataSource id='postgresql-mydb' jdbcDriverRef='postgresql-driver' jndiName='jdbc/mydb'
            transactional='true' type='javax.sql.ConnectionPoolDataSource'>
        <properties id='postgresql-mydb-props' 
          databaseName='${cloud.services.mydb.connection.name}'
          user='${cloud.services.mydb.connection.user}'
          password='${cloud.services.mydb.connection.password}' 
          portNumber='${cloud.services.mydb.connection.port}'
          serverName='${cloud.services.mydb.connection.host}'/> 
</dataSource>    

<jdbcDriver id='postgresql-driver' 
            javax.sql.XADataSource='org.postgresql.xa.PGXADataSource'
            javax.sql.ConnectionPoolDataSource='org.postgresql.ds.PGConnectionPoolDataSource'            
            libraryRef='postgresql-library'/>  

<library id='postgresql-library'>       
	    <fileset id='postgresql-fileset'  dir='${server.config.dir}/lib'
        includes='postgresql-jdbc-9.3.1102.jar'/>   
</library>

With this configuration, the datasource should be accessible using Java code similar to the following:

import javax.annotation.Resource
import javax.sql.DataSource

...

@Resource(name = "jdbc/mydb")
private DataSource mydb;

The configuration elements in the server.xml file use the following IDs and ID formats:

  • The dataSource element uses a configuration ID of postgresql-service_name.
  • The properties element uses a configuration ID of postgresql-service_name-props.
  • The jdbcDriver element uses a configuration ID of postgresql-driver.
  • The library element uses a configuration ID of postgresql-library.
  • The fileset element uses a configuration ID of postgresql-fileset.

If the Liberty buildpack finds an existing data source configuration, it updates only the following attributes:

  • databaseName
  • user
  • password
  • serverName
  • portNumber

The Liberty buildpack does not update the jndiName attribute.

You can provide your own client driver JAR files. The client driver JAR files must be placed in the usr/servers/<servername>/lib directory. If you do not provide client driver JAR files, the Liberty buildpack provides the files for you. The client driver JAR files that you provide must use the standard names that are established by the providing vendor. You cannot rename client JAR files.