By default, the repository configuration is stored in the
$HOME/midpoint directory of the user the application server runs as. This directory is further referenced to as
This directory will be created upon the very first start of midPoint. The configuration file config.xml will be generated if it does not exist and it will be pre-configured to use the embedded H2 repository. You can first start midPoint with embedded H2 repository and then reconfigure the created
config.xml to use another database, or you can prepare
config.xml before the midPoint starts for the very first time using the sample configurations (see the child pages below).
Default values are used only if repository is in embedded mode, otherwise configuration validation fails.
|database||Simplified option for repository setup. Possible values are h2, mysql, oracle, sqlserver, postgresql. This option will set defaults for other options, for example embedded, hibernateHbm2ddl, hibernateDialect and driverClassName based on selected database. These defaults can be overridden by specifying custom values in configuration.||h2|
Drops database files if they exist during start. Useful for tests.
Directory where H2 files will be saved if we're running in embedded mode.
current folder "."
Database filename. Name for H2 files if we're running in embedded mode.
Embedded H2 mode.
This option can be used if we're running in H2 embedded mode. If the server mode is turned on, H2 runs with TCP server. Other applications/services can connect to H2 server. If false, H2 runs in file mode.
Embedded H2 server mode SSL.
Embedded H2 server mode port.
Automatically validates or exports schema DDL to the database when the SessionFactory is created. E.g.
For production environments,
SQL dialect based on choosen DB Supported hibernate dialects.
Uses JNDI DataSource loading, when this option is defined in configuration, then jdbcUsername, jdbcPassword, jdbcUrl and driverClassName don't need to be present. E.g. <dataSource>java:comp/env/jdbc/midpoint</dataSource>
Username for JDBC connection.
sa (if embedded=true), null (otherwise)
Password for JDBC connection.
empty string (if embedded=true), null (otherwise)
URL for JDBC connection.
if embedded=true url is computed from previous parameters
Driver class name for JDBC connection.
org.h2.Driver (if embedded=true)
|useZip||Property provides optional compression for full XML column.||false|
|minPoolSize||Minimal # of connections in connection pool, if connection pool is not provided through dataSource.||8|
|maxPoolSize||Maximum # of connections in connection pool, if connection pool is not provided through dataSource.||20|
|cacheMaxTTL||Option which can enable caching of selected object types (ConnectorType, ObjectTemplateType, SecurityPolicyType, SystemConfigurationType and ValuePolicyType). Objects are cached and reloaded only if object version doesn't match. Version check happens only after time to live (TTL) period has passed. Value in seconds.||0|
|initializationFailTimeout||Hikari pool initialization failure timeout, in milliseconds. It is there to allow midPoint to wait until the repository is up and running and therefore to avoid failing prematurely. Introduced in midPoint 3.9.||1 ms (effectively keeping the behavior as it was before midPoint 3.9)|
Using empty username and password
MidPoint 4.2 and later
It is possible to connect to the database without specifying password or username or both. Examples are PostgreSQL trust authentication (though definitely not recommended for serious deployments) or Microsoft SQL Server with integrated security.
Simply skip configuration elements jdbcUsername and jdbcPassword. If everything is configured as expected, connection will be successful, otherwise JDBC driver will throw an exception and midPoint will not start.
Schema creation and updating
MidPoint 3.9 and later
In midPoint 3.9 we have implemented a more flexible and powerful approach to schema validation and maintenance. It replaces the standard Hibernate ORM approach. It is enabled by setting
hibernateHbm2ddl parameter to
none, which is now the default for non-H2 databases.
What it does:
- First, it determines the state of the database schema by:
- running standard Hibernate schema validation procedure (just like
- examining explicit schema version by looking at parameter
m_global_metadatatable. This is a new table introduced in midPoint 3.9.
- running standard Hibernate schema validation procedure (just like
- Then it acts upon these data, either by
- continuing with the midPoint startup process,
- stopping the midPoint startup process with an appropriate error message,
- or trying to remediate the situation e.g. by running a schema creation or schema upgrade SQL script.
Schema validation and maintenance is the driven by these configuration options:
|skipExplicitSchemaValidation||Whether to skip this process of explicit schema validation.|
What to do if the database schema is not present:
What to do if the database schema is present but it is outdated and it seems to be upgradeable:
Note that currently (as of 3.9) the only supported automated upgrade is from 3.8 to 3.9.
Please consider carefully whether you want to run this automatic upgrade also for the production environment. It is perhaps better to still run the upgrade manually in such situation.
What to do if the database schema is present, is not compatible and not upgradeable. A typical example is when the schema is newer than the current version of midPoint.
|schemaVersionIfMissing||If the schema version cannot be determined from ||(none)|
|schemaVersionOverride||Overrides any schema version information in the ||(none)|
Used to specify what schema variant is to be used for automated creation or upgrade of the database schema. Currently the only known variant is
Beware: it is the administrator's responsibility to choose the correct variant! Currently midPoint does not try to determine the variant present in the database. So be sure to avoid applying e.g.
|createMissingCustomColumns||(Since 4.2) If true, midPoint tries to alter tables with custom columns (currently only in audit) if the column is missing. Intended for test, not for production usage.|
Schema creation and updating (before 3.9)
In earlier versions of midPoint the schema creation and update is driven solely by the
hibernateHbm2ddl parameter. For production environments it is strongly recommended to set it to
validate that is the default value for non-H2 databases. Then you have to maintain it manually using SQL scripts which are located in the distribution package
SQL schema scripts for all supported databases are located in midPoint distribution package which is downloadable from download page for current release.
For current unreleased MidPoint SQL scripts are located in our git.
Data source configuration
Instead of putting JDBC configuration to config.xml, you can use data source of the application server.
This is obsolete functionality. It is no longer supported or maintained.
It is relevant only for WAR deployments which are not recommended deployment model since midPoint 4.0.
There are two steps for configuring data sources. Data source configuration is common for all supported databases.
First step is DB resource configuration in application server. Here is example for Tomcat 7. This XML part is located in
<tomcat-location>/conf/server.xml, resource will be available for all applications in container.
Next step is configuration in file
config.xmllocated in midpoint.home folder.
hibernateDialectdepends on your DB choice,
dataSourceis based on resource name.
- What is midPoint Open Source Identity & Access Management
- Evolveum - Team of IAM professionals who developed midPoint