diff --git a/authorization_services/topics/enforcer-js-adapter.adoc b/authorization_services/topics/enforcer-js-adapter.adoc index 0e2506b44f..d758d8e60b 100644 --- a/authorization_services/topics/enforcer-js-adapter.adoc +++ b/authorization_services/topics/enforcer-js-adapter.adoc @@ -60,7 +60,7 @@ Most applications should use the `onGrant` callback to retry a request after a 4 The keycloak-authz.js library provides an `entitlement` function that you can use to obtain an RPT from the server using the Entitlement API. -```json +```javascript authorization.entitlement('my-resource-server-id').then(function (rpt) { // onGrant callback function. // If authorization was successful you'll receive an RPT diff --git a/authorization_services/topics/resource-server-create-client.adoc b/authorization_services/topics/resource-server-create-client.adoc index f548cfa8a9..8d3a47a8e7 100644 --- a/authorization_services/topics/resource-server-create-client.adoc +++ b/authorization_services/topics/resource-server-create-client.adoc @@ -18,7 +18,7 @@ image:{project_images}/resource-server/client-create.png[alt="Create Client"] . Type the `Client ID` of the client. For example, _my-resource-server_. . Type the `Root URL` for your application. For example: + -```bash +``` http://${host}:${port}/my-resource-server ``` diff --git a/authorization_services/topics/service-authorization-authorization-api-aapi.adoc b/authorization_services/topics/service-authorization-authorization-api-aapi.adoc index c0bc2929f5..a81dc9e0f9 100644 --- a/authorization_services/topics/service-authorization-authorization-api-aapi.adoc +++ b/authorization_services/topics/service-authorization-authorization-api-aapi.adoc @@ -6,7 +6,7 @@ This token consists of all the permissions granted to a user as a result of the With an RPT, client applications can gain access to protected resources at the resource server. .UMA compliant Authorization API Endpoint -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/authz/authorize ``` diff --git a/authorization_services/topics/service-entitlement-entitlement-api-aapi.adoc b/authorization_services/topics/service-entitlement-entitlement-api-aapi.adoc index 556cb0765d..82412ca53a 100644 --- a/authorization_services/topics/service-entitlement-entitlement-api-aapi.adoc +++ b/authorization_services/topics/service-entitlement-entitlement-api-aapi.adoc @@ -6,7 +6,7 @@ This token consists of all the entitlements (or permissions) for a user as a res With an RPT, client applications can gain access to protected resources at the resource server. .Entitlement API Endpoint -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/authz/entitlement/{client_id} ``` diff --git a/authorization_services/topics/service-protection-permission-api-papi.adoc b/authorization_services/topics/service-protection-permission-api-papi.adoc index 7e1e4e777d..3628faf189 100644 --- a/authorization_services/topics/service-protection-permission-api-papi.adoc +++ b/authorization_services/topics/service-protection-permission-api-papi.adoc @@ -3,7 +3,7 @@ Resource servers using the UMA protocol can use a specific endpoint to manage permission requests. This endpoint provides a UMA-compliant flow for registering permission requests and obtaining a permission ticket. -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/authz/protection/permission ``` diff --git a/authorization_services/topics/service-protection-resources-api-papi.adoc b/authorization_services/topics/service-protection-resources-api-papi.adoc index e42d3c9948..e7778acc9c 100644 --- a/authorization_services/topics/service-protection-resources-api-papi.adoc +++ b/authorization_services/topics/service-protection-resources-api-papi.adoc @@ -3,7 +3,7 @@ Resource servers can manage their resources remotely using a UMA-compliant endpoint. -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set ``` diff --git a/authorization_services/topics/service-protection-resources-api.adoc b/authorization_services/topics/service-protection-resources-api.adoc index e42d3c9948..e7778acc9c 100644 --- a/authorization_services/topics/service-protection-resources-api.adoc +++ b/authorization_services/topics/service-protection-resources-api.adoc @@ -3,7 +3,7 @@ Resource servers can manage their resources remotely using a UMA-compliant endpoint. -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/authz/protection/resource_set ``` diff --git a/authorization_services/topics/service-protection-whatis-obtain-pat.adoc b/authorization_services/topics/service-protection-whatis-obtain-pat.adoc index 8193c528a4..0c807c0f3b 100644 --- a/authorization_services/topics/service-protection-whatis-obtain-pat.adoc +++ b/authorization_services/topics/service-protection-whatis-obtain-pat.adoc @@ -18,7 +18,7 @@ curl -X POST \ The example above is using the *client_credentials* grant type to obtain a PAT from the server. As a result, the server returns a response similar to the following: -```bash +```json { "access_token": ${PAT}, "expires_in": 300, diff --git a/authorization_services/topics/service-rpt-token-introspection.adoc b/authorization_services/topics/service-rpt-token-introspection.adoc index 475246f1b5..afb7138d6f 100644 --- a/authorization_services/topics/service-rpt-token-introspection.adoc +++ b/authorization_services/topics/service-rpt-token-introspection.adoc @@ -12,7 +12,7 @@ There are two main use cases where token introspection can help you: The token introspection is essentially a https://tools.ietf.org/html/rfc7662[OAuth2 token introspection]-compliant endpoint from which you can obtain information about an RPT. -```bash +``` http://${host}:${port}/auth/realms/${realm_name}/protocol/openid-connect/token/introspect ``` diff --git a/securing_apps/topics/oidc/java/application-clustering.adoc b/securing_apps/topics/oidc/java/application-clustering.adoc index d54be1148c..9259d3e41a 100644 --- a/securing_apps/topics/oidc/java/application-clustering.adoc +++ b/securing_apps/topics/oidc/java/application-clustering.adoc @@ -85,7 +85,7 @@ Sending startup registrations and periodic re-registration is disabled by defaul To enable the feature edit the `WEB-INF/keycloak.json` file for your application and add: -[source] +[source,json] ---- "register-node-at-startup": true, "register-node-period": 600, @@ -105,7 +105,7 @@ request. This may have a performance impact as your application will send more r To enable the feature edit the `WEB-INF/keycloak.json` file for your application and add: -[source] +[source,json] ---- "always-refresh-token": true ---- diff --git a/securing_apps/topics/oidc/java/client-authentication.adoc b/securing_apps/topics/oidc/java/client-authentication.adoc index 9f1facb133..9c09d594e4 100644 --- a/securing_apps/topics/oidc/java/client-authentication.adoc +++ b/securing_apps/topics/oidc/java/client-authentication.adoc @@ -9,7 +9,7 @@ This is the traditional method described in the OAuth2 specification. The client You can generate the secret for a particular client in the {project_name} administration console, and then paste this secret into the `keycloak.json` file on the application side: -[source] +[source,json] ---- "credentials": { "secret": "19666a4f-32dd-4049-b082-684c74115f28" @@ -36,7 +36,7 @@ For more details on how to set up the {project_name} administration console see For set up on the adapter side you need to have something like this in your `keycloak.json` file: -[source] +[source,json] ---- "credentials": { "jwt": { @@ -62,7 +62,7 @@ This is the same as Client Authentication with Signed JWT except for using the c The client has a secret, which needs to be known to both the adapter (application) and the {project_name} server. You need to choose `Signed JWT with Client Secret` as the method of authenticating your client in the tab `Credentials` in administration console, and then paste this secret into the `keycloak.json` file on the application side: -[source] +[source,json] ---- "credentials": { "secret-jwt": { diff --git a/securing_apps/topics/oidc/java/fuse/hawtio.adoc b/securing_apps/topics/oidc/java/fuse/hawtio.adoc index eb596057a2..6a679ce599 100644 --- a/securing_apps/topics/oidc/java/fuse/hawtio.adoc +++ b/securing_apps/topics/oidc/java/fuse/hawtio.adoc @@ -115,7 +115,7 @@ To run Hawtio on the {fuseHawtioEAPVersion} server, complete the following steps . Restart the {fuseHawtioEAPVersion} server with Hawtio: + -[source,xml] +[source,bash] ---- cd $EAP_HOME/bin ./standalone.sh -Djboss.socket.binding.port-offset=101 diff --git a/securing_apps/topics/oidc/java/installed-adapter.adoc b/securing_apps/topics/oidc/java/installed-adapter.adoc index 07cb733852..4bec82a002 100644 --- a/securing_apps/topics/oidc/java/installed-adapter.adoc +++ b/securing_apps/topics/oidc/java/installed-adapter.adoc @@ -67,7 +67,7 @@ through the `KeycloakInstalled` constructor. In the example below, the client configuration for `desktop-app` uses the following `keycloak.json`: -[source] +[source,json] ---- { @@ -82,7 +82,7 @@ uses the following `keycloak.json`: ---- the following sketch demonstrates working with the `KeycloakInstalled` adapter: -[source] +[source,java] ---- // reads the configuration from classpath: META-INF/keycloak.json @@ -111,7 +111,7 @@ login / logout requests via the `loginResponseWriter` and `logoutResponseWriter` The following provides an example for the configuration mentioned above. -[source] +[source,java] ---- import java.util.Locale; import java.util.concurrent.Executors; diff --git a/securing_apps/topics/oidc/java/jboss-adapter.adoc b/securing_apps/topics/oidc/java/jboss-adapter.adoc index edd1e02630..340bd606cb 100644 --- a/securing_apps/topics/oidc/java/jboss-adapter.adoc +++ b/securing_apps/topics/oidc/java/jboss-adapter.adoc @@ -298,7 +298,7 @@ If you have multiple deployments secured by the same realm you can share the rea To propagate the security context to the EJB tier you need to configure it to use the "keycloak" security domain. This can be achieved with the @SecurityDomain annotation: -[source] +[source,java] ---- import org.jboss.ejb3.annotation.SecurityDomain; diff --git a/securing_apps/topics/oidc/java/jetty9-adapter.adoc b/securing_apps/topics/oidc/java/jetty9-adapter.adoc index 8b4f4e03ee..813397a113 100644 --- a/securing_apps/topics/oidc/java/jetty9-adapter.adoc +++ b/securing_apps/topics/oidc/java/jetty9-adapter.adoc @@ -107,7 +107,7 @@ Finally you must specify both a `login-config` and use standard servlet security Here's an example: -[source] +[source,xml] ---- diff --git a/securing_apps/topics/oidc/java/spring-security-adapter.adoc b/securing_apps/topics/oidc/java/spring-security-adapter.adoc index 1c1886e680..c10d36098b 100644 --- a/securing_apps/topics/oidc/java/spring-security-adapter.adoc +++ b/securing_apps/topics/oidc/java/spring-security-adapter.adoc @@ -32,7 +32,7 @@ The implementation allows customization by overriding methods. While its use is not required, it greatly simplifies your security context configuration. -[source] +[source,java] ---- @@ -84,7 +84,7 @@ for the {project_name} adapter. While Spring Security's XML namespace simplifies configuration, customizing the configuration can be a bit verbose. -[source] +[source,xml] ---- @@ -171,7 +171,7 @@ To enable this feature your security configuration must add the `KeycloakRestTem Note that it must be scoped as a prototype to function correctly. For Java configuration: -[source] +[source,java] ---- @@ -196,7 +196,7 @@ public class SecurityConfig extends KeycloakWebSecurityConfigurerAdapter { ---- For XML configuration: -[source] +[source,xml] ---- @@ -207,7 +207,7 @@ For XML configuration: Your application code can then use `KeycloakRestTemplate` any time it needs to make a call to another client. For example: -[source] +[source,java] ---- @@ -234,7 +234,7 @@ The Spring Boot and the Spring Security adapters can be combined. If you are using the Keycloak Spring Boot Starter to make use of the Spring Security adapter you just need to add the Spring Security starter : -[source] +[source,xml] ---- @@ -248,7 +248,7 @@ If you are using the Keycloak Spring Boot Starter to make use of the Spring Secu By Default, the Spring Security Adapter looks for a `keycloak.json` configuration file. You can make sure it looks at the configuration provided by the Spring Boot Adapter by adding this bean : -[source] +[source,java] ---- @Bean @@ -264,7 +264,7 @@ Spring Boot attempts to eagerly register filter beans with the web application c Therefore, when running the Keycloak Spring Security adapter in a Spring Boot environment, it may be necessary to add two ``FilterRegistrationBean``s to your security configuration to prevent the Keycloak filters from being registered twice. -[source] +[source,java] ---- diff --git a/securing_apps/topics/oidc/java/tomcat-adapter.adoc b/securing_apps/topics/oidc/java/tomcat-adapter.adoc index 2c64ce4f98..84c4980445 100644 --- a/securing_apps/topics/oidc/java/tomcat-adapter.adoc +++ b/securing_apps/topics/oidc/java/tomcat-adapter.adoc @@ -52,7 +52,7 @@ Finally you must specify both a `login-config` and use standard servlet security Here's an example: -[source] +[source,xml] ---- diff --git a/securing_apps/topics/oidc/javascript-adapter.adoc b/securing_apps/topics/oidc/javascript-adapter.adoc index fbfa411e84..109d60e9c1 100644 --- a/securing_apps/topics/oidc/javascript-adapter.adoc +++ b/securing_apps/topics/oidc/javascript-adapter.adoc @@ -62,7 +62,7 @@ redirected back to the application and remain unauthenticated. To enable `login-required` set `onLoad` to `login-required` and pass to the init method: -[source] +[source,javascript] ---- keycloak.init({ onLoad: 'login-required' }) ---- diff --git a/securing_apps/topics/oidc/mod-auth-openidc.adoc b/securing_apps/topics/oidc/mod-auth-openidc.adoc index c8030efd5b..fe113f55ce 100644 --- a/securing_apps/topics/oidc/mod-auth-openidc.adoc +++ b/securing_apps/topics/oidc/mod-auth-openidc.adoc @@ -15,7 +15,7 @@ To configure _mod_auth_openidc_ you'll need An example configuration would look like the following. -[source,xml] +[source] ---- LoadModule auth_openidc_module modules/mod_auth_openidc.so diff --git a/securing_apps/topics/saml/java/error_handling.adoc b/securing_apps/topics/saml/java/error_handling.adoc index 31d8781a50..e4220b6d65 100644 --- a/securing_apps/topics/saml/java/error_handling.adoc +++ b/securing_apps/topics/saml/java/error_handling.adoc @@ -22,7 +22,7 @@ This class can tell you exactly what happened. If this attribute is not set, then the adapter was not responsible for the error code. -[source,javascript] +[source,java] ---- public class SamlAuthenticationError implements AuthenticationError { public static enum Reason { diff --git a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc index 5069672bc4..786823a96b 100644 --- a/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc +++ b/securing_apps/topics/saml/java/jboss-adapter/jboss_adapter_installation.adoc @@ -122,7 +122,7 @@ Otherwise this configuration is optional. For example, if you have a JAX-RS service that is an EJB within your WEB-INF/classes directory, you'll want to annotate it with the `@SecurityDomain` annotation as follows: -[source,xml] +[source,java] ---- import org.jboss.ejb3.annotation.SecurityDomain; diff --git a/securing_apps/topics/token-exchange/token-exchange.adoc b/securing_apps/topics/token-exchange/token-exchange.adoc index 925cc79584..4b0861eb02 100644 --- a/securing_apps/topics/token-exchange/token-exchange.adoc +++ b/securing_apps/topics/token-exchange/token-exchange.adoc @@ -74,6 +74,7 @@ A successful response from an exchange invocation will return the HTTP 200 respo depends on the `requested-token-type` and `requested_issuer` the client asks for. OAuth requested token types will return a JSON document as described in the link:https://www.ietf.org/id/draft-ietf-oauth-token-exchange-12.txt[OAuth Token Exchange] specification. +[source,json] ---- { "access_token" : ".....", @@ -90,6 +91,7 @@ Error responses generally fall under the 400 HTTP response code category, but ot depending on the severity of the error. Error responses may include content depending on the `requested_issuer`. OAuth based exchanges may return a JSON document as follows: +[source,json] ---- { "error" : "...." diff --git a/server_admin/topics/authentication/flows.adoc b/server_admin/topics/authentication/flows.adoc index 86d5100467..d8eb7bbf9f 100644 --- a/server_admin/topics/authentication/flows.adoc +++ b/server_admin/topics/authentication/flows.adoc @@ -78,7 +78,7 @@ a `org.jboss.logging.Logger` scoped to `ScriptBasedAuthenticator` Note that additional context information can be extracted from the `context` argument passed to the `authenticate(context)` `action(context)` function. -[source] +[source,javascript] ---- AuthenticationFlowError = Java.type("org.keycloak.authentication.AuthenticationFlowError"); diff --git a/server_admin/topics/authentication/kerberos.adoc b/server_admin/topics/authentication/kerberos.adoc index 54cd3f3280..07804c30a2 100644 --- a/server_admin/topics/authentication/kerberos.adoc +++ b/server_admin/topics/authentication/kerberos.adoc @@ -157,7 +157,7 @@ Applications will need to deserialize the claim it receives from {project_name} Once you deserialize the credential from the access token to the GSSCredential object, the GSSContext will need to be created with this credential passed to the method `GSSManager.createContext` for example like this: -[source] +[source,java] ---- // Obtain accessToken in your application. KeycloakPrincipal keycloakPrincipal = (KeycloakPrincipal) servletReq.getUserPrincipal(); diff --git a/server_admin/topics/authentication/x509.adoc b/server_admin/topics/authentication/x509.adoc index fff6f3b5c8..301c202abe 100644 --- a/server_admin/topics/authentication/x509.adoc +++ b/server_admin/topics/authentication/x509.adoc @@ -59,7 +59,7 @@ Enable mutual SSL in WildFly:: See link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-EnableSSL[Enable SSL] and link:https://docs.jboss.org/author/display/WFLY10/Admin+Guide#AdminGuide-%7B%7B%3Cssl%2F%3E%7D%7D[SSL] for the instructions how to enable SSL in Wildfly. * Open {project_dirref}/standalone/configuration/standalone.xml and add a new realm: -``` +```xml diff --git a/server_admin/topics/identity-broker/suggested.adoc b/server_admin/topics/identity-broker/suggested.adoc index 55fdb3f79e..bde10340ae 100644 --- a/server_admin/topics/identity-broker/suggested.adoc +++ b/server_admin/topics/identity-broker/suggested.adoc @@ -11,7 +11,7 @@ at the application. For example -[source,java] +[source] ---- GET /myapplication.com?kc_idp_hint=facebook HTTP/1.1 Host: localhost:8080 @@ -21,7 +21,7 @@ In this case, is expected that your realm has an identity provider with an alias If you are using `keycloak.js` adapter, you can also achieve the same behavior: -[source,java] +[source,javascript] ---- var keycloak = new Keycloak('keycloak.json'); diff --git a/server_admin/topics/identity-broker/tokens.adoc b/server_admin/topics/identity-broker/tokens.adoc index 495a26b47d..6bf42326ad 100644 --- a/server_admin/topics/identity-broker/tokens.adoc +++ b/server_admin/topics/identity-broker/tokens.adoc @@ -8,7 +8,7 @@ Application code can retrieve these tokens and responses to pull in extra user i For example, an application might want to use the Google token to invoke on other Google services and REST APIs. To retrieve a token for a particular identity provider you need to send a request as follows: -[source,java] +[source] ---- GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1 Host: localhost:8080 diff --git a/server_development/topics/auth-spi.adoc b/server_development/topics/auth-spi.adoc index e4de0ac7eb..8e690f9373 100644 --- a/server_development/topics/auth-spi.adoc +++ b/server_development/topics/auth-spi.adoc @@ -433,7 +433,7 @@ This jar does not have to be separate from other provider classes but it must co This file must list the fully qualified classname of each RequiredActionFactory implementation you have in the jar. For example: -[source,java] +[source] ---- org.keycloak.examples.authenticator.SecretQuestionRequiredActionFactory ---- @@ -704,7 +704,7 @@ This jar must contain a file named `org.keycloak.authentication.FormActionFacto This file must list the fully qualified classname of each FormActionFactory implementation you have in the jar. For example: -[source,java] +[source] ---- org.keycloak.authentication.forms.RegistrationProfile diff --git a/server_development/topics/identity-brokering/account-linking.adoc b/server_development/topics/identity-brokering/account-linking.adoc index e37ffa5eaa..0a58db30bf 100644 --- a/server_development/topics/identity-brokering/account-linking.adoc +++ b/server_development/topics/identity-brokering/account-linking.adoc @@ -20,7 +20,7 @@ There are some preconditions that must be met by the client application before i To initiate the login, the application must fabricate a URL and redirect the user's browser to this URL. The URL looks like this: -[source,java] +[source] ---- /{auth-server-root}/auth/realms/{realm}/broker/{provider}/link?client_id={id}&redirect_uri={uri}&nonce={nonce}&hash={hash} ---- diff --git a/server_development/topics/identity-brokering/tokens.adoc b/server_development/topics/identity-brokering/tokens.adoc index 495a26b47d..6bf42326ad 100644 --- a/server_development/topics/identity-brokering/tokens.adoc +++ b/server_development/topics/identity-brokering/tokens.adoc @@ -8,7 +8,7 @@ Application code can retrieve these tokens and responses to pull in extra user i For example, an application might want to use the Google token to invoke on other Google services and REST APIs. To retrieve a token for a particular identity provider you need to send a request as follows: -[source,java] +[source] ---- GET /auth/realms/{realm}/broker/{provider_alias}/token HTTP/1.1 Host: localhost:8080 diff --git a/server_development/topics/providers.adoc b/server_development/topics/providers.adoc index 640c58891d..02d4998b43 100644 --- a/server_development/topics/providers.adoc +++ b/server_development/topics/providers.adoc @@ -183,7 +183,7 @@ KEYCLOAK_HOME/bin/jboss-cli.sh --command="module add --name=org.acme.provider -- Or to manually create it start by creating the folder `KEYCLOAK_HOME/modules/org/acme/provider/main`. Then copy `provider.jar` to this folder and create `module.xml` with the following content: -[source] +[source,xml] ---- diff --git a/server_development/topics/themes.adoc b/server_development/topics/themes.adoc index f571b3ad97..6885bdc955 100644 --- a/server_development/topics/themes.adoc +++ b/server_development/topics/themes.adoc @@ -310,7 +310,7 @@ For example for the `mytheme` theme create `mytheme.zip` with the contents: The contents of `META-INF/keycloak-themes.json` in this case would be: -[source,javascript] +[source,json] ---- { "themes": [{ diff --git a/server_installation/topics/proxy.adoc b/server_installation/topics/proxy.adoc index fd1b845fd3..ded020bfcf 100644 --- a/server_installation/topics/proxy.adoc +++ b/server_installation/topics/proxy.adoc @@ -27,7 +27,7 @@ If you do not specify a path to the proxy config file, the launcher will look in === Proxy Configuration Here's an example configuration file. -[source] +[source,json] ---- { @@ -231,7 +231,7 @@ KEYCLOAK_ACCESS_TOKEN:: Send the access token in this header if the proxy was configured to send it. This token can be used to make bearer token requests. Header field names can be configured using a map of `header-names` in configuration file: + -[source] +[source,json] ---- { diff --git a/upgrading/topics/keycloak/changes.adoc b/upgrading/topics/keycloak/changes.adoc index c9a39413ee..c5a84ea697 100644 --- a/upgrading/topics/keycloak/changes.adoc +++ b/upgrading/topics/keycloak/changes.adoc @@ -314,7 +314,7 @@ We added support for offline tokens in this release, which means that we are per If you are not using offline tokens, nothing will be persisted for you, so you don't need to care about worse performance for more DB writes. However in all cases, you will need to update `standalone/configuration/keycloak-server.json` and add `userSessionPersister` like this: -[source] +[source,json] ---- "userSessionPersister": { "provider": "jpa" diff --git a/upgrading/topics/migrate_db.adoc b/upgrading/topics/migrate_db.adoc index 41cde56526..6e2f795c3c 100644 --- a/upgrading/topics/migrate_db.adoc +++ b/upgrading/topics/migrate_db.adoc @@ -10,6 +10,8 @@ database is automatically migrated when you start the new installation for the f To enable automatic upgrading of the database schema, set the migrationStrategy property value to "update" for the default connectionsJpa provider: +[source,xml] +---- @@ -18,6 +20,7 @@ default connectionsJpa provider: +---- Or run this CLI command: @@ -34,6 +37,8 @@ in the new version. To enable manual upgrading of the database schema, set the migrationStrategy property value to "manual" for the default connectionsJpa provider: +[source,xml] +---- @@ -42,6 +47,7 @@ connectionsJpa provider: +---- Or run this CLI command: