Cause
The company spring data related configuration is still a bit of meaning, but quite complicated ... XML many ... I'm not too fond of forcing to remember .... So I'm going to take a look at the general idea and structure of the configuration that might be useful later ....
Overall structure
The overall structure is roughly the same. Spring/data This folder mainly configures the spring data related configuration.
There are 2 main folders under Data: DataSource and module, and some other XML and properties
XML and Propertiesdata-context.xml
<resource= "Data-source-context.xml"/> < resource= "Spring-data-context.xml"/>
View Code
This is a simple file that introduces 2 other configuration files.
Not just spring Data. Other and spring-integrated tools will have such 1 configuration files, such as Cache,basecode, to record other profiles to be introduced. Probably a configuration list ... Nothing really works except introducing other configuration files
Data-source-context.xml
The main purpose of this document is about 2:
1. Loading the configuration under the DataSource folder, you can see that we have 3 data sources
2. Configure JTA Global transactions, which are cross-data sources. So it will not be configured in DataSource.
Data.properties
This file is more common, the configuration is the development Environment database address, account number, password and other information. Only the development environment, and the test environment and the actual production environment through the Web container through Jndi to provide the data source
Spring-data-context.xml
The main purpose of this configuration file:
1. Load the configuration under Module, module represents the project can be divided into multiple modules, each module may use different data sources, you can see our project is divided into 4 modules
2. Load some 4 modules common repository (we use spring Data JPA here, so to indicate which repository to load):
DataSource Directory
The configuration files in this directory are mainly used for configuration data sources.
We can see that we mainly use 3 data sources.
The configuration of each data source consists of 2 files
Zg-jpa-context.xml
This file is configured with the JPA entity manager corresponding to this data source
<BeanID= "Zgentitymanagerfactory"class= "Org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> < Propertyname= "Persistenceunitname"value= "Sbf-zg-db" /> < Propertyname= "DataSource"ref= "Zgdatasource"/> < Propertyname= "Jpadialect"> <Beanclass= "Org.springframework.orm.jpa.vendor.HibernateJpaDialect" /> </ Property> < Propertyname= "Jpavendoradapter"> <Beanclass= "Org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"> < Propertyname= "Database"value= "ORACLE" /> </Bean> </ Property> < Propertyname= "Packagestoscan"> <Array> </Array> </ Property> < Propertyname= "Mappingresources"value= "Sql/zs-named-query.xml"/> < Propertyname= "Jpapropertymap"> <Map> <entryKey= "Hibernate.show_sql"value= "${service." Jpa. LOG. ENABLED} " /> <entryKey= "Hibernate.format_sql"value= "${service." Jpa. LOG. ENABLED} " /> </Map> </ Property> < Propertyname= "Persistenceunitpostprocessors"> <List> <Beanclass= "XXX". Dynamicpersistenceunitpostprocessor "> < Propertyname= "DatabaseName"value= "ZG"/> </Bean> </List> </ Property> </Bean>
View Code
Configuring the Entity Manager primarily requires configuring Packagestoscan. Use is to load entity, map the table in the database
The reason why we do not configure this property here is because we have configured our own written persistenceunitpostprocessor, see the name to know that it is a post-processor, can enhance the function of the original persistenceunit. We are in this class of our own to load the module configured under the entity ... So the equivalent of the Packagestoscan to load the entity moved here to load the .... But I have not found any merit in this moment ....
Data-source-context.xml
The main purpose of this file:
1. Configure the data sources that the previous JPA entity manager needs to use.
2. Use the previous entity manager to configure the TransactionManager
<BeanID= "Zgtransactionmanager"class= "Org.springframework.orm.jpa.JpaTransactionManager"> < Propertyname= "Entitymanagerfactory"ref= "Zgentitymanagerfactory" /> </Bean> <Beans Profile= "Development,default"> <BeanID= "Zgdatasource"class= "Org.apache.commons.dbcp.BasicDataSource"Destroy-method= "Close"Scope= "Singleton"> < Propertyname= "Driverclassname"> <value>${data.datasource.zg.jdbc.driver}</value> </ Property> < Propertyname= "url"> <value>${data.datasource.zg.jdbc.url}</value> </ Property> < Propertyname= "username"> <value>${data.datasource.zg.jdbc.username}</value> </ Property> < Propertyname= "Password"> <value>${data.datasource.zg.jdbc.password}</value> </ Property> </Bean> </Beans> <Beans Profile= "PROD"> <Jee:jndi-lookupID= "Zgdatasource"Jndi-name= "Jdbc/zgdatasource" /> </Beans>
View Code
From the code you can see the development environment and production environment, the test environment uses the data source configuration is different.
The data sources for development are defined in data.properties, while the data sources for test and production environments refer to the data sources configured in WebLogic through Jndi methods.
The advantage is probably the development of the source code, modify the data.properties switch development, test library is more convenient ... While the production environment does not modify the code, it is convenient to modify the data source directly from the WebLogic console ...
In addition, I think it seems more reasonable to put TransactionManager configuration in Zg-jpa-context.xml. Because the data source should be as long as the configuration data source is enough. It doesn't seem to matter to TransactionManager. But there's nothing wrong with putting it down here.
Module folder
Module is the classification of the specific business of the project ... We can see that we have 4 modules here. DJ,RD,SB and ZS
There are 2 configurations under each module ... than in the SB directory (there are actually 3 of them.) There are 2 spring-data-context-xx.xml. Just because we are different around. 2 files are the same for each other).
Data-mapping.properties
hx.sb.mapping.package=xxx.sb.cmp,yyy.cmpqz.sb.mapping.package=xxx.cmpzg.sb.mapping.package=xxx.cmp
View Code
Do you remember the persistenceunitpostprocessor we wrote in front of us? The postprocessor needs to load the managed entity to map the database. What is the path to these entity? Those paths are defined in this properties.
From the properties of the key we can see different data source loading of the entity is different, we have defined 3 data sources, SB This module 3 data sources need to use (in fact, as long as 2, the middle of the NX is a differentiated configuration), So we need 3 pairs of key-value pairs to indicate which entity the 3 data sources need to load ... In other modules, if only 1 data sources are used, it is only necessary to write the managed entity that the data source needs to be loaded ...
So here is the sub-module management entity: This is an advantage, in the self-test can be divided into modules to load the data source, rather than a full load of brain ... But it's only theoretically ... In fact everyone for convenience, will not write additional configuration files. Finally, the outermost configuration file is loaded ... Equivalent to all data sources and entity loaded ... Anyway, ... This is a bit of a meaning configuration ...
Spring-data-context-standard.xml
Standard can be modified into other. than the NX in.
These configuration files are differentiated. There are different configurations around ...
The purpose of this configuration file is to load the repository that spring data JPA needs to use.
<jpa:repositoriesBase-package= "GOV.GT3.IITMS.SBF"Entity-manager-factory-ref= "Hxentitymanagerfactory"Transaction-manager-ref= "Hxtransactionmanager"Factory-class= "Org.springframework.data.jpa.repository.support.CustomRepositoryFactoryBean"> <Repository:include-filtertype= "Regex"expression= "gov\.gt3\.iitms\.sbf\.sb\.repository\." [^.] *repository " /> <Repository:include-filtertype= "Regex"expression= "gov\.gt3\.iitms\.sbf\.sb\.batch\.standard\.plkk\.repository\." [^.] *repository " /> </jpa:repositories> <jpa:repositoriesBase-package= "GOV.GT3.IITMS.SBF"Entity-manager-factory-ref= "Zgentitymanagerfactory"Transaction-manager-ref= "Zgtransactionmanager"Factory-class= "Org.springframework.data.jpa.repository.support.CustomRepositoryFactoryBean"> <Repository:include-filtertype= "Regex"expression= "gov\.gt3\.iitms\.sbf\.sb\.repository\.cxtj\." [^.] *repository " /> </jpa:repositories>
View Code
For example, I'm going to use 2 data sources here. That except for these 2 data sources the corresponding entity is configured in the JPA Entity Manager configuration (mentioned earlier): There is also a need to configure where the repository needs to be loaded ...
That means you can have a Entity.java 2 repository that corresponds to 2 data sources ....
Anyway, this module to use a few data sources, here to load these data sources to use the Repository...repository equivalent is the path of data storage, so it is followed the data source to go ...
Summarize
There's nothing to summarize ... Above is the main usage of the company ... You don't need to be so complicated to play with your own simple ... Do not know how other companies are configured ... When I have a new discovery, I'll add ...
Record sharing company Spring data related configuration