To override the default settings just define a @Bean
of your own of type DataSource
.
Spring Boot provides a utility builder class DataSourceBuilder
that can be used
to create one of the standard ones (if it is on the classpath), or you can just create
your own, and bind it to a set of Environment
properties as explained in
Section 24.7.1, “Third-party configuration”, e.g.
@Bean @ConfigurationProperties(prefix="datasource.mine") public DataSource dataSource() { return new FancyDataSource(); }
datasource.mine.jdbcUrl=jdbc:h2:mem:mydb datasource.mine.user=sa datasource.mine.poolSize=30
See Section 29.1, “Configure a DataSource” in the
‘Spring Boot features’ section and the
DataSourceAutoConfiguration
class for more details.
Tip | |
---|---|
You could also do that if you want to configure a JNDI data-source. @Bean(destroyMethod="") @ConfigurationProperties(prefix="datasource.mine") public DataSource dataSource() throws Exception { JndiDataSourceLookup dataSourceLookup = new JndiDataSourceLookup(); return dataSourceLookup.getDataSource("java:comp/env/jdbc/YourDS"); } |
Creating more than one data source works the same as creating the first one. You might
want to mark one of them as @Primary
if you are using the default auto-configuration for
JDBC or JPA (then that one will be picked up by any @Autowired
injections).
@Bean @Primary @ConfigurationProperties(prefix="datasource.primary") public DataSource primaryDataSource() { return DataSourceBuilder.create().build(); } @Bean @ConfigurationProperties(prefix="datasource.secondary") public DataSource secondaryDataSource() { return DataSourceBuilder.create().build(); }
Spring Data can create implementations for you of @Repository
interfaces of various
flavors. Spring Boot will handle all of that for you as long as those @Repositories
are included in the same package (or a sub-package) of your @EnableAutoConfiguration
class.
For many applications all you will need is to put the right Spring Data dependencies on
your classpath (there is a spring-boot-starter-data-jpa
for JPA and a
spring-boot-starter-data-mongodb
for Mongodb), create some repository interfaces to handle your
@Entity
objects. Examples are in the JPA sample
or the Mongodb sample.
Spring Boot tries to guess the location of your @Repository
definitions, based on the
@EnableAutoConfiguration
it finds. To get more control, use the @EnableJpaRepositories
annotation (from Spring Data JPA).
Spring Boot tries to guess the location of your @Entity
definitions, based on the
@EnableAutoConfiguration
it finds. To get more control, you can use the @EntityScan
annotation, e.g.
@Configuration @EnableAutoConfiguration @EntityScan(basePackageClasses=City.class) public class Application { //... }
Spring Data JPA already provides some vendor-independent configuration options (e.g. for SQL logging) and Spring Boot exposes those, and a few more for hibernate as external configuration properties. The most common options to set are:
spring.jpa.hibernate.ddl-auto=create-drop spring.jpa.hibernate.naming.physical-strategy=com.example.MyPhysicalNamingStrategy spring.jpa.database=H2 spring.jpa.show-sql=true
The ddl-auto
setting is a special case in that it has different defaults depending on
whether you are using an embedded database (create-drop
) or not (none
). In addition
all properties in spring.jpa.properties.*
are passed through as normal JPA properties
(with the prefix stripped) when the local EntityManagerFactory
is created.
Spring Boot provides a consistent naming strategy regardless of the Hibernate generation
that you are using. If you are using Hibernate 4, you can customize it using
spring.jpa.hibernate.naming.strategy
; Hibernate 5 defines a Physical
and Implicit
naming strategies: Spring Boot configures SpringPhysicalNamingStrategy
by default. This
implementation provides the same table structure as Hibernate 4. If you’d rather use
Hibernate 5’s default instead, set the following property:
spring.jpa.hibernate.naming.physical-strategy=org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl
See HibernateJpaAutoConfiguration
and JpaBaseConfiguration
for more details.
To take full control of the configuration of the EntityManagerFactory
, you need to add
a @Bean
named ‘entityManagerFactory’. Spring Boot auto-configuration switches off its
entity manager based on the presence of a bean of that type.
Even if the default EntityManagerFactory
works fine, you will need to define a new one
because otherwise the presence of the second bean of that type will switch off the
default. To make it easy to do that you can use the convenient EntityManagerBuilder
provided by Spring Boot, or if you prefer you can just use the
LocalContainerEntityManagerFactoryBean
directly from Spring ORM.
Example:
// add two data sources configured as above @Bean public LocalContainerEntityManagerFactoryBean customerEntityManagerFactory( EntityManagerFactoryBuilder builder) { return builder .dataSource(customerDataSource()) .packages(Customer.class) .persistenceUnit("customers") .build(); } @Bean public LocalContainerEntityManagerFactoryBean orderEntityManagerFactory( EntityManagerFactoryBuilder builder) { return builder .dataSource(orderDataSource()) .packages(Order.class) .persistenceUnit("orders") .build(); }
The configuration above almost works on its own. To complete the picture you need to
configure TransactionManagers
for the two EntityManagers
as well. One of them could
be picked up by the default JpaTransactionManager
in Spring Boot if you mark it as
@Primary
. The other would have to be explicitly injected into a new instance. Or you
might be able to use a JTA transaction manager spanning both.
If you are using Spring Data, you need to configure @EnableJpaRepositories
accordingly:
@Configuration @EnableJpaRepositories(basePackageClasses = Customer.class, entityManagerFactoryRef = "customerEntityManagerFactory") public class CustomerConfiguration { ... } @Configuration @EnableJpaRepositories(basePackageClasses = Order.class, entityManagerFactoryRef = "orderEntityManagerFactory") public class OrderConfiguration { ... }
Spring doesn’t require the use of XML to configure the JPA provider, and Spring Boot
assumes you want to take advantage of that feature. If you prefer to use persistence.xml
then you need to define your own @Bean
of type LocalEntityManagerFactoryBean
(with
id ‘entityManagerFactory’, and set the persistence unit name there.
See
JpaBaseConfiguration
for the default settings.
Spring Data JPA and Spring Data Mongo can both create Repository
implementations for you
automatically. If they are both present on the classpath, you might have to do some extra
configuration to tell Spring Boot which one (or both) you want to create repositories for
you. The most explicit way to do that is to use the standard Spring Data
@Enable*Repositories
and tell it the location of your Repository
interfaces
(where ‘*’ is ‘Jpa’ or ‘Mongo’ or both).
There are also flags spring.data.*.repositories.enabled
that you can use to switch the
auto-configured repositories on and off in external configuration. This is useful for
instance in case you want to switch off the Mongo repositories and still use the
auto-configured MongoTemplate
.
The same obstacle and the same features exist for other auto-configured Spring Data repository types (Elasticsearch, Solr). Just change the names of the annotations and flags respectively.
Spring Data REST can expose the Repository
implementations as REST endpoints for you as
long as Spring MVC has been enabled for the application.
Spring Boot exposes as set of useful properties from the spring.data.rest
namespace that
customize the
RepositoryRestConfiguration
.
If you need to provide additional customization, you should use a
RepositoryRestConfigurer
bean.