WORKERS AHEAD!

You are viewing the development documentation for the Apereo CAS server. The functionality presented here is not officially released yet. This is a work in progress and will be continually updated as development moves forward. You are most encouraged to test the changes presented.

Server-side Sessions - JDBC

If you don’t wish to use the native container’s strategy for session replication, you can use CAS’s support for JDBC session replication.

This feature is enabled via the following module:

<dependency>
    <groupId>org.apereo.cas</groupId>
    <artifactId>cas-server-support-session-jdbc</artifactId>
    <version>${cas.version}</version>
</dependency>

implementation "org.apereo.cas:cas-server-support-session-jdbc:${project.'cas.version'}"

dependencyManagement {
    imports {
        mavenBom "org.apereo.cas:cas-server-support-bom:${project.'cas.version'}"
    }
}

dependencies {
    implementation "org.apereo.cas:cas-server-support-session-jdbc"
}

dependencies {
    /*
        The following platform references should be included automatically and are listed here for reference only.

        implementation enforcedPlatform("org.apereo.cas:cas-server-support-bom:${project.'cas.version'}")
        implementation platform(org.springframework.boot.gradle.plugin.SpringBootPlugin.BOM_COORDINATES)
        
    */
    implementation "org.apereo.cas:cas-server-support-session-jdbc"
}

The following settings and properties are available from the CAS configuration catalog:

_{The configuration settings listed below are tagged as Required in the CAS configuration metadata. This flag indicates that the presence of the setting may be needed to activate or affect the behavior of the CAS feature and generally should be reviewed, possibly owned and adjusted. If the setting is assigned a default value, you do not need to strictly put the setting in your copy of the configuration, but should review it nonetheless to make sure it matches your deployment expectations.}

_{The configuration settings listed below are tagged as Optional in the CAS configuration metadata. This
flag indicates that the presence of the setting
is not immediately necessary in the end-user CAS configuration, because a default value is assigned or
the activation of the feature is not conditionally controlled by the setting value. In other words, you should only include this field in your
configuration if you need to modify the default value or if you need to turn on the feature controlled by the setting.}

_{The configuration settings listed below are tagged as Third Party in the CAS configuration metadata. This flag indicates that the configuration setting is not controlled, owned or managed by the CAS ecosystem, and affects functionality that is offered by a third-party library, such as Spring Boot or Spring Cloud to CAS. For additional info, you might have to visit the third-party source to find more details.}

spring.datasource.azure.credential.client-certificate-password=

Password of the certificate file.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

When possible, properties should be stored in lower-case kebab format, such as cas.property-name=value. The only possible exception to this rule is when naming actuator endpoints; The name of the actuator endpoints (i.e. ssoSessions) MUST remain in camelCase mode.

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.client-certificate-password=...

This is the most common form of property configuration that is recognized by CAS, regardless of the actual property source, which might in fact be managed separately outside the CAS environment, by another system or cloud framework.

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        client-certificate-password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.client-certificate-password="..." -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory. Note the placement of the system property which must be specified before the CAS web application is launched.

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_CLIENT_CERTIFICATE_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.client-certificate-password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.client-certificate-path=

Path of a PEM certificate file to use when performing service principal authentication with Azure.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.client-certificate-path=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        client-certificate-path: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.client-certificate-path="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_CLIENT_CERTIFICATE_PATH="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.client-certificate-path="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.client-id=

Client ID to use when performing service principal authentication with Azure.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.client-id=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        client-id: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.client-id="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_CLIENT_ID="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.client-id="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.client-secret=

Client secret to use when performing service principal authentication with Azure.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.client-secret=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        client-secret: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.client-secret="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_CLIENT_SECRET="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.client-secret="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.managed-identity-enabled=false

Whether to enable managed identity to authenticate with Azure. If true and the client-id is set, will use the client ID as user assigned managed identity client ID.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.managed-identity-enabled=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        managed-identity-enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.managed-identity-enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_MANAGED_IDENTITY_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.managed-identity-enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.password=

Password to use when performing username/password authentication with Azure.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.credential.username=

Username to use when performing username/password authentication with Azure.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.credential.username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      credential: 
        username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.credential.username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_CREDENTIAL_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.credential.username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.passwordless-enabled=false

Whether to enable passwordless connections to Azure databases by using OAuth2 Microsoft Entra token credentials.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.passwordless-enabled=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      passwordless-enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.passwordless-enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_PASSWORDLESS_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.passwordless-enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.profile.cloud-type=

Name of the Azure cloud to connect to. Supported types are: AZURE, AZURE_CHINA, AZURE_US_GOVERNMENT, OTHER. The default value is `AZURE`.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.profile.cloud-type=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      profile: 
        cloud-type: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.profile.cloud-type="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_PROFILE_CLOUD_TYPE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.profile.cloud-type="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.profile.environment.active-directory-endpoint=

The Microsoft Entra endpoint to connect to.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.profile.environment.active-directory-endpoint=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      profile: 
        environment: 
          active-directory-endpoint: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.profile.environment.active-directory-endpoint="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_PROFILE_ENVIRONMENT_ACTIVE_DIRECTORY_ENDPOINT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.profile.environment.active-directory-endpoint="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.azure.profile.tenant-id=

Tenant ID for Azure resources. The values allowed for 'tenant-id' are: 'common', 'organizations', 'consumers', or the tenant ID.

com.azure.spring.cloud.autoconfigure.implementation.passwordless.properties.AzureJdbcPasswordlessProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.azure.profile.tenant-id=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    azure: 
      profile: 
        tenant-id: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.azure.profile.tenant-id="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_AZURE_PROFILE_TENANT_ID="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.azure.profile.tenant-id="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.continue-on-error=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.continue-on-error=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    continue-on-error: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.continue-on-error="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_CONTINUE_ON_ERROR="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.continue-on-error="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.continue-on-error.

spring.datasource.data=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.data=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    data: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.data="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DATA="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.data="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.data-locations.

spring.datasource.data-password=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.data-password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    data-password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.data-password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DATA_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.data-password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.password.

spring.datasource.data-username=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.data-username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    data-username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.data-username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DATA_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.data-username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.username.

spring.datasource.dbcp2.abandoned-usage-tracking=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.abandoned-usage-tracking=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      abandoned-usage-tracking: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.abandoned-usage-tracking="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_ABANDONED_USAGE_TRACKING="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.abandoned-usage-tracking="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.access-to-underlying-connection-allowed=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.access-to-underlying-connection-allowed=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      access-to-underlying-connection-allowed: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.access-to-underlying-connection-allowed="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_ACCESS_TO_UNDERLYING_CONNECTION_ALLOWED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.access-to-underlying-connection-allowed="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.auto-commit-on-return=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.auto-commit-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      auto-commit-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.auto-commit-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_AUTO_COMMIT_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.auto-commit-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.cache-state=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.cache-state=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      cache-state: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.cache-state="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_CACHE_STATE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.cache-state="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.clear-statement-pool-on-return=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.clear-statement-pool-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      clear-statement-pool-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.clear-statement-pool-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_CLEAR_STATEMENT_POOL_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.clear-statement-pool-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.connection-factory-class-name=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.connection-factory-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      connection-factory-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.connection-factory-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_CONNECTION_FACTORY_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.connection-factory-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.connection-init-sqls=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.connection-init-sqls=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      connection-init-sqls: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.connection-init-sqls="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_CONNECTION_INIT_SQLS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.connection-init-sqls="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.default-auto-commit=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-auto-commit=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-auto-commit: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-auto-commit="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_AUTO_COMMIT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-auto-commit="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.default-catalog=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-catalog=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-catalog: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-catalog="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_CATALOG="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-catalog="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.default-query-timeout=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-query-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-query-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-query-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_QUERY_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-query-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.default-read-only=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-read-only=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-read-only: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-read-only="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_READ_ONLY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-read-only="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.default-schema=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-schema=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-schema: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-schema="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_SCHEMA="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-schema="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.default-transaction-isolation=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.default-transaction-isolation=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      default-transaction-isolation: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.default-transaction-isolation="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DEFAULT_TRANSACTION_ISOLATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.default-transaction-isolation="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.disconnection-ignore-sql-codes=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.disconnection-ignore-sql-codes=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      disconnection-ignore-sql-codes: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.disconnection-ignore-sql-codes="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DISCONNECTION_IGNORE_SQL_CODES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.disconnection-ignore-sql-codes="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.disconnection-sql-codes=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.disconnection-sql-codes=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      disconnection-sql-codes: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.disconnection-sql-codes="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DISCONNECTION_SQL_CODES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.disconnection-sql-codes="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.driver-class-name=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.driver-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      driver-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.driver-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DRIVER_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.driver-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.duration-between-eviction-runs=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.duration-between-eviction-runs=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      duration-between-eviction-runs: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.duration-between-eviction-runs="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_DURATION_BETWEEN_EVICTION_RUNS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.duration-between-eviction-runs="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.enable-auto-commit-on-return=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.enable-auto-commit-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      enable-auto-commit-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.enable-auto-commit-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_ENABLE_AUTO_COMMIT_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.enable-auto-commit-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.eviction-policy-class-name=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.eviction-policy-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      eviction-policy-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.eviction-policy-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_EVICTION_POLICY_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.eviction-policy-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.fast-fail-validation=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.fast-fail-validation=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      fast-fail-validation: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.fast-fail-validation="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_FAST_FAIL_VALIDATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.fast-fail-validation="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.initial-size=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.initial-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      initial-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.initial-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_INITIAL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.initial-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.jmx-name=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.jmx-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      jmx-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.jmx-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_JMX_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.jmx-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.lifo=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.lifo=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      lifo: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.lifo="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_LIFO="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.lifo="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.log-abandoned=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.log-abandoned=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      log-abandoned: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.log-abandoned="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_LOG_ABANDONED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.log-abandoned="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.log-expired-connections=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.log-expired-connections=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      log-expired-connections: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.log-expired-connections="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_LOG_EXPIRED_CONNECTIONS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.log-expired-connections="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.login-timeout=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.login-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      login-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.login-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_LOGIN_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.login-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.max-conn-lifetime-millis=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.max-conn-lifetime-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      max-conn-lifetime-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.max-conn-lifetime-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MAX_CONN_LIFETIME_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.max-conn-lifetime-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.max-idle=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.max-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      max-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.max-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MAX_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.max-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.max-open-prepared-statements=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.max-open-prepared-statements=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      max-open-prepared-statements: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.max-open-prepared-statements="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MAX_OPEN_PREPARED_STATEMENTS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.max-open-prepared-statements="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.max-total=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.max-total=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      max-total: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.max-total="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MAX_TOTAL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.max-total="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.max-wait-millis=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.max-wait-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      max-wait-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.max-wait-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MAX_WAIT_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.max-wait-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.min-evictable-idle-time-millis=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.min-evictable-idle-time-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      min-evictable-idle-time-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.min-evictable-idle-time-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MIN_EVICTABLE_IDLE_TIME_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.min-evictable-idle-time-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.min-idle=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.min-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      min-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.min-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_MIN_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.min-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.num-tests-per-eviction-run=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.num-tests-per-eviction-run=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      num-tests-per-eviction-run: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.num-tests-per-eviction-run="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_NUM_TESTS_PER_EVICTION_RUN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.num-tests-per-eviction-run="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.password=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.pool-prepared-statements=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.pool-prepared-statements=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      pool-prepared-statements: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.pool-prepared-statements="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_POOL_PREPARED_STATEMENTS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.pool-prepared-statements="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.remove-abandoned-on-borrow=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.remove-abandoned-on-borrow=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      remove-abandoned-on-borrow: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.remove-abandoned-on-borrow="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_REMOVE_ABANDONED_ON_BORROW="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.remove-abandoned-on-borrow="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.remove-abandoned-on-maintenance=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.remove-abandoned-on-maintenance=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      remove-abandoned-on-maintenance: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.remove-abandoned-on-maintenance="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_REMOVE_ABANDONED_ON_MAINTENANCE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.remove-abandoned-on-maintenance="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.remove-abandoned-timeout=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.remove-abandoned-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      remove-abandoned-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.remove-abandoned-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_REMOVE_ABANDONED_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.remove-abandoned-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.rollback-on-return=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.rollback-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      rollback-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.rollback-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_ROLLBACK_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.rollback-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.soft-min-evictable-idle-time-millis=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.soft-min-evictable-idle-time-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      soft-min-evictable-idle-time-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.soft-min-evictable-idle-time-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_SOFT_MIN_EVICTABLE_IDLE_TIME_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.soft-min-evictable-idle-time-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.test-on-borrow=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.test-on-borrow=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      test-on-borrow: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.test-on-borrow="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_TEST_ON_BORROW="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.test-on-borrow="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.test-on-create=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.test-on-create=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      test-on-create: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.test-on-create="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_TEST_ON_CREATE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.test-on-create="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.test-on-return=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.test-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      test-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.test-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_TEST_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.test-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.test-while-idle=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.test-while-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      test-while-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.test-while-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_TEST_WHILE_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.test-while-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.time-between-eviction-runs-millis=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.time-between-eviction-runs-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      time-between-eviction-runs-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.time-between-eviction-runs-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_TIME_BETWEEN_EVICTION_RUNS_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.time-between-eviction-runs-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.dbcp2.url=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.url=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      url: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.url="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_URL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.url="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.username=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.validation-query=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.validation-query=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      validation-query: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.validation-query="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_VALIDATION_QUERY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.validation-query="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.dbcp2.validation-query-timeout=

org.apache.commons.dbcp2.BasicDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.dbcp2.validation-query-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    dbcp2: 
      validation-query-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.dbcp2.validation-query-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DBCP2_VALIDATION_QUERY_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.dbcp2.validation-query-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.driver-class-name=

Fully qualified name of the JDBC driver. Auto-detected based on the URL by default.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.driver-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    driver-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.driver-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_DRIVER_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.driver-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.embedded-database-connection=

Connection details for an embedded database. Defaults to the most suitable embedded database that is available on the classpath.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.embedded-database-connection=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    embedded-database-connection: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.embedded-database-connection="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_EMBEDDED_DATABASE_CONNECTION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.embedded-database-connection="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.generate-unique-name=true

Whether to generate a random datasource name.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.generate-unique-name=true

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    generate-unique-name: "true"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.generate-unique-name="true" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_GENERATE_UNIQUE_NAME="true"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.generate-unique-name="true"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.allow-pool-suspension=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.allow-pool-suspension=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      allow-pool-suspension: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.allow-pool-suspension="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_ALLOW_POOL_SUSPENSION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.allow-pool-suspension="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.auto-commit=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.auto-commit=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      auto-commit: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.auto-commit="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_AUTO_COMMIT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.auto-commit="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.catalog=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.catalog=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      catalog: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.catalog="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_CATALOG="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.catalog="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.connection-init-sql=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.connection-init-sql=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      connection-init-sql: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.connection-init-sql="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_CONNECTION_INIT_SQL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.connection-init-sql="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.connection-test-query=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.connection-test-query=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      connection-test-query: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.connection-test-query="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_CONNECTION_TEST_QUERY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.connection-test-query="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.connection-timeout=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.connection-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      connection-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.connection-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_CONNECTION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.connection-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.data-source-class-name=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.data-source-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      data-source-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.data-source-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_DATA_SOURCE_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.data-source-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.data-source-j-n-d-i=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.data-source-j-n-d-i=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      data-source-j-n-d-i: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.data-source-j-n-d-i="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_DATA_SOURCE_J_N_D_I="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.data-source-j-n-d-i="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.data-source-properties=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.data-source-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      data-source-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.data-source-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_DATA_SOURCE_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.data-source-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.driver-class-name=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.driver-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      driver-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.driver-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_DRIVER_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.driver-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.exception-override-class-name=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.exception-override-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      exception-override-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.exception-override-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_EXCEPTION_OVERRIDE_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.exception-override-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.health-check-properties=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.health-check-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      health-check-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.health-check-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_HEALTH_CHECK_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.health-check-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.idle-timeout=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.idle-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      idle-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.idle-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_IDLE_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.idle-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.initialization-fail-timeout=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.initialization-fail-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      initialization-fail-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.initialization-fail-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_INITIALIZATION_FAIL_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.initialization-fail-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.isolate-internal-queries=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.isolate-internal-queries=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      isolate-internal-queries: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.isolate-internal-queries="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_ISOLATE_INTERNAL_QUERIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.isolate-internal-queries="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.jdbc-url=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.jdbc-url=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      jdbc-url: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.jdbc-url="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_JDBC_URL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.jdbc-url="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.keepalive-time=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.keepalive-time=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      keepalive-time: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.keepalive-time="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_KEEPALIVE_TIME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.keepalive-time="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.leak-detection-threshold=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.leak-detection-threshold=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      leak-detection-threshold: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.leak-detection-threshold="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_LEAK_DETECTION_THRESHOLD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.leak-detection-threshold="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.login-timeout=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.login-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      login-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.login-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_LOGIN_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.login-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.max-lifetime=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.max-lifetime=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      max-lifetime: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.max-lifetime="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_MAX_LIFETIME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.max-lifetime="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.maximum-pool-size=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.maximum-pool-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      maximum-pool-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.maximum-pool-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_MAXIMUM_POOL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.maximum-pool-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.minimum-idle=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.minimum-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      minimum-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.minimum-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.minimum-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.password=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.pool-name=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.pool-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      pool-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.pool-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_POOL_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.pool-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.read-only=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.read-only=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      read-only: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.read-only="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_READ_ONLY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.read-only="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.register-mbeans=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.register-mbeans=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      register-mbeans: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.register-mbeans="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_REGISTER_MBEANS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.register-mbeans="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.schema=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.schema=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      schema: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.schema="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_SCHEMA="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.schema="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.transaction-isolation=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.transaction-isolation=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      transaction-isolation: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.transaction-isolation="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_TRANSACTION_ISOLATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.transaction-isolation="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.username=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.hikari.validation-timeout=

com.zaxxer.hikari.HikariDataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.hikari.validation-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    hikari: 
      validation-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.hikari.validation-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_HIKARI_VALIDATION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.hikari.validation-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.initialization-mode=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.initialization-mode=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    initialization-mode: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.initialization-mode="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_INITIALIZATION_MODE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.initialization-mode="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.mode.

spring.datasource.jmx-enabled=false

Whether to enable JMX support (if provided by the underlying pool).

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.jmx-enabled=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    jmx-enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.jmx-enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_JMX_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.jmx-enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.datasource.tomcat.jmx-enabled.

spring.datasource.jndi-name=

JNDI location of the datasource. Class, url, username and password are ignored when set.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.jndi-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    jndi-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.jndi-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_JNDI_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.jndi-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.name=

Datasource name to use if "generate-unique-name" is false. Defaults to "testdb" when using an embedded database, otherwise null.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.abandoned-connection-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.abandoned-connection-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      abandoned-connection-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.abandoned-connection-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_ABANDONED_CONNECTION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.abandoned-connection-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.commit-on-connection-return=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.commit-on-connection-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      commit-on-connection-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.commit-on-connection-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_COMMIT_ON_CONNECTION_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.commit-on-connection-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-factory-class-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-factory-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-factory-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-factory-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_FACTORY_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-factory-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-factory-properties=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-factory-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-factory-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-factory-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_FACTORY_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-factory-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-harvest-max-count=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-harvest-max-count=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-harvest-max-count: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-harvest-max-count="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_HARVEST_MAX_COUNT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-harvest-max-count="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-harvest-trigger-count=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-harvest-trigger-count=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-harvest-trigger-count: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-harvest-trigger-count="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_HARVEST_TRIGGER_COUNT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-harvest-trigger-count="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-labeling-high-cost=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-labeling-high-cost=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-labeling-high-cost: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-labeling-high-cost="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_LABELING_HIGH_COST="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-labeling-high-cost="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-pool-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-pool-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-pool-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-pool-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_POOL_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-pool-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-properties=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-repurpose-threshold=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-repurpose-threshold=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-repurpose-threshold: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-repurpose-threshold="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_REPURPOSE_THRESHOLD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-repurpose-threshold="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-validation-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-validation-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-validation-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-validation-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_VALIDATION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-validation-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-wait-duration=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-wait-duration=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-wait-duration: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-wait-duration="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_WAIT_DURATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-wait-duration="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.connection-wait-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.connection-wait-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      connection-wait-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.connection-wait-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CONNECTION_WAIT_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.connection-wait-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is WARNINGwithout a replacement setting.

spring.datasource.oracleucp.create-connection-in-borrow-thread=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.create-connection-in-borrow-thread=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      create-connection-in-borrow-thread: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.create-connection-in-borrow-thread="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_CREATE_CONNECTION_IN_BORROW_THREAD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.create-connection-in-borrow-thread="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.data-source-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.data-source-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      data-source-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.data-source-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_DATA_SOURCE_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.data-source-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.database-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.database-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      database-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.database-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_DATABASE_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.database-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.description=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.description=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      description: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.description="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_DESCRIPTION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.description="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.fast-connection-failover-enabled=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.fast-connection-failover-enabled=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      fast-connection-failover-enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.fast-connection-failover-enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_FAST_CONNECTION_FAILOVER_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.fast-connection-failover-enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.high-cost-connection-reuse-threshold=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.high-cost-connection-reuse-threshold=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      high-cost-connection-reuse-threshold: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.high-cost-connection-reuse-threshold="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_HIGH_COST_CONNECTION_REUSE_THRESHOLD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.high-cost-connection-reuse-threshold="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.inactive-connection-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.inactive-connection-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      inactive-connection-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.inactive-connection-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_INACTIVE_CONNECTION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.inactive-connection-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.initial-pool-size=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.initial-pool-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      initial-pool-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.initial-pool-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_INITIAL_POOL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.initial-pool-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.login-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.login-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      login-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.login-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_LOGIN_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.login-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-connection-reuse-count=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-connection-reuse-count=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-connection-reuse-count: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-connection-reuse-count="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_CONNECTION_REUSE_COUNT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-connection-reuse-count="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-connection-reuse-time=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-connection-reuse-time=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-connection-reuse-time: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-connection-reuse-time="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_CONNECTION_REUSE_TIME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-connection-reuse-time="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-connections-per-shard=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-connections-per-shard=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-connections-per-shard: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-connections-per-shard="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_CONNECTIONS_PER_SHARD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-connections-per-shard="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-idle-time=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-idle-time=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-idle-time: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-idle-time="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_IDLE_TIME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-idle-time="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-pool-size=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-pool-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-pool-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-pool-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_POOL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-pool-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.max-statements=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.max-statements=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      max-statements: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.max-statements="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MAX_STATEMENTS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.max-statements="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.min-idle=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.min-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      min-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.min-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MIN_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.min-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.min-pool-size=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.min-pool-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      min-pool-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.min-pool-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_MIN_POOL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.min-pool-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.network-protocol=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.network-protocol=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      network-protocol: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.network-protocol="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_NETWORK_PROTOCOL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.network-protocol="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.o-n-s-configuration=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.o-n-s-configuration=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      o-n-s-configuration: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.o-n-s-configuration="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_O_N_S_CONFIGURATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.o-n-s-configuration="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.pdb-roles=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.pdb-roles=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      pdb-roles: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.pdb-roles="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_PDB_ROLES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.pdb-roles="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.port-number=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.port-number=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      port-number: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.port-number="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_PORT_NUMBER="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.port-number="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.property-cycle=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.property-cycle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      property-cycle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.property-cycle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_PROPERTY_CYCLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.property-cycle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.query-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.query-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      query-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.query-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_QUERY_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.query-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.read-only-instance-allowed=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.read-only-instance-allowed=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      read-only-instance-allowed: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.read-only-instance-allowed="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_READ_ONLY_INSTANCE_ALLOWED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.read-only-instance-allowed="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.role-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.role-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      role-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.role-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_ROLE_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.role-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.s-q-l-for-validate-connection=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.s-q-l-for-validate-connection=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      s-q-l-for-validate-connection: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.s-q-l-for-validate-connection="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_S_Q_L_FOR_VALIDATE_CONNECTION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.s-q-l-for-validate-connection="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.seconds-to-trust-idle-connection=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.seconds-to-trust-idle-connection=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      seconds-to-trust-idle-connection: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.seconds-to-trust-idle-connection="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_SECONDS_TO_TRUST_IDLE_CONNECTION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.seconds-to-trust-idle-connection="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.server-name=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.server-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      server-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.server-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_SERVER_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.server-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.sharding-mode=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.sharding-mode=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      sharding-mode: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.sharding-mode="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_SHARDING_MODE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.sharding-mode="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.time-to-live-connection-timeout=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.time-to-live-connection-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      time-to-live-connection-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.time-to-live-connection-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_TIME_TO_LIVE_CONNECTION_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.time-to-live-connection-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.timeout-check-interval=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.timeout-check-interval=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      timeout-check-interval: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.timeout-check-interval="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_TIMEOUT_CHECK_INTERVAL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.timeout-check-interval="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.u-r-l=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.u-r-l=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      u-r-l: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.u-r-l="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_U_R_L="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.u-r-l="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.user=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.user=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      user: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.user="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_USER="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.user="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.oracleucp.validate-connection-on-borrow=

oracle.ucp.jdbc.PoolDataSourceImpl.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.oracleucp.validate-connection-on-borrow=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    oracleucp: 
      validate-connection-on-borrow: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.oracleucp.validate-connection-on-borrow="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_ORACLEUCP_VALIDATE_CONNECTION_ON_BORROW="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.oracleucp.validate-connection-on-borrow="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.password=

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.platform=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.platform=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    platform: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.platform="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_PLATFORM="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.platform="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.platform.

spring.datasource.schema=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.schema=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    schema: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.schema="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_SCHEMA="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.schema="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.schema-locations.

spring.datasource.schema-password=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.schema-password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    schema-password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.schema-password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_SCHEMA_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.schema-password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.password.

spring.datasource.schema-username=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.schema-username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    schema-username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.schema-username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_SCHEMA_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.schema-username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.username.

spring.datasource.separator=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.separator=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    separator: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.separator="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_SEPARATOR="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.separator="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.separator.

spring.datasource.sql-script-encoding=

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.sql-script-encoding=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    sql-script-encoding: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.sql-script-encoding="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_SQL_SCRIPT_ENCODING="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.sql-script-encoding="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

Deprecation status is ERRORwith a replacement setting: spring.sql.init.encoding.

spring.datasource.tomcat.abandon-when-percentage-full=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.abandon-when-percentage-full=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      abandon-when-percentage-full: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.abandon-when-percentage-full="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_ABANDON_WHEN_PERCENTAGE_FULL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.abandon-when-percentage-full="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.access-to-underlying-connection-allowed=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.access-to-underlying-connection-allowed=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      access-to-underlying-connection-allowed: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.access-to-underlying-connection-allowed="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_ACCESS_TO_UNDERLYING_CONNECTION_ALLOWED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.access-to-underlying-connection-allowed="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.alternate-username-allowed=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.alternate-username-allowed=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      alternate-username-allowed: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.alternate-username-allowed="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_ALTERNATE_USERNAME_ALLOWED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.alternate-username-allowed="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.commit-on-return=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.commit-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      commit-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.commit-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_COMMIT_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.commit-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.connection-properties=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.connection-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      connection-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.connection-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_CONNECTION_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.connection-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.data-source-j-n-d-i=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.data-source-j-n-d-i=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      data-source-j-n-d-i: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.data-source-j-n-d-i="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DATA_SOURCE_J_N_D_I="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.data-source-j-n-d-i="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.db-properties=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.db-properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      db-properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.db-properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DB_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.db-properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.default-auto-commit=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.default-auto-commit=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      default-auto-commit: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.default-auto-commit="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DEFAULT_AUTO_COMMIT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.default-auto-commit="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.default-catalog=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.default-catalog=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      default-catalog: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.default-catalog="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DEFAULT_CATALOG="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.default-catalog="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.default-read-only=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.default-read-only=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      default-read-only: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.default-read-only="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DEFAULT_READ_ONLY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.default-read-only="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.default-transaction-isolation=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.default-transaction-isolation=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      default-transaction-isolation: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.default-transaction-isolation="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DEFAULT_TRANSACTION_ISOLATION="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.default-transaction-isolation="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.driver-class-name=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.driver-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      driver-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.driver-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_DRIVER_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.driver-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.fair-queue=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.fair-queue=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      fair-queue: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.fair-queue="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_FAIR_QUEUE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.fair-queue="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.ignore-exception-on-pre-load=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.ignore-exception-on-pre-load=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      ignore-exception-on-pre-load: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.ignore-exception-on-pre-load="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_IGNORE_EXCEPTION_ON_PRE_LOAD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.ignore-exception-on-pre-load="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.init-s-q-l=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.init-s-q-l=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      init-s-q-l: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.init-s-q-l="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_INIT_S_Q_L="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.init-s-q-l="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.initial-size=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.initial-size=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      initial-size: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.initial-size="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_INITIAL_SIZE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.initial-size="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.jdbc-interceptors=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.jdbc-interceptors=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      jdbc-interceptors: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.jdbc-interceptors="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_JDBC_INTERCEPTORS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.jdbc-interceptors="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.jmx-enabled=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.jmx-enabled=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      jmx-enabled: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.jmx-enabled="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_JMX_ENABLED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.jmx-enabled="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.log-abandoned=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.log-abandoned=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      log-abandoned: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.log-abandoned="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_LOG_ABANDONED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.log-abandoned="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.log-validation-errors=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.log-validation-errors=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      log-validation-errors: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.log-validation-errors="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_LOG_VALIDATION_ERRORS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.log-validation-errors="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.login-timeout=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.login-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      login-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.login-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_LOGIN_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.login-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.max-active=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.max-active=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      max-active: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.max-active="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MAX_ACTIVE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.max-active="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.max-age=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.max-age=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      max-age: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.max-age="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MAX_AGE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.max-age="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.max-idle=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.max-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      max-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.max-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MAX_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.max-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.max-wait=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.max-wait=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      max-wait: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.max-wait="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MAX_WAIT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.max-wait="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.min-evictable-idle-time-millis=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.min-evictable-idle-time-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      min-evictable-idle-time-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.min-evictable-idle-time-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MIN_EVICTABLE_IDLE_TIME_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.min-evictable-idle-time-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.min-idle=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.min-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      min-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.min-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_MIN_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.min-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.name=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.num-tests-per-eviction-run=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.num-tests-per-eviction-run=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      num-tests-per-eviction-run: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.num-tests-per-eviction-run="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_NUM_TESTS_PER_EVICTION_RUN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.num-tests-per-eviction-run="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.password=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.password=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      password: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.password="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_PASSWORD="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.password="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.propagate-interrupt-state=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.propagate-interrupt-state=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      propagate-interrupt-state: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.propagate-interrupt-state="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_PROPAGATE_INTERRUPT_STATE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.propagate-interrupt-state="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.remove-abandoned=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.remove-abandoned=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      remove-abandoned: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.remove-abandoned="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_REMOVE_ABANDONED="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.remove-abandoned="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.remove-abandoned-timeout=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.remove-abandoned-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      remove-abandoned-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.remove-abandoned-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_REMOVE_ABANDONED_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.remove-abandoned-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.rollback-on-return=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.rollback-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      rollback-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.rollback-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_ROLLBACK_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.rollback-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.suspect-timeout=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.suspect-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      suspect-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.suspect-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_SUSPECT_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.suspect-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.test-on-borrow=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.test-on-borrow=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      test-on-borrow: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.test-on-borrow="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_TEST_ON_BORROW="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.test-on-borrow="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.test-on-connect=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.test-on-connect=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      test-on-connect: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.test-on-connect="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_TEST_ON_CONNECT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.test-on-connect="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.test-on-return=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.test-on-return=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      test-on-return: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.test-on-return="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_TEST_ON_RETURN="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.test-on-return="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.test-while-idle=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.test-while-idle=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      test-while-idle: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.test-while-idle="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_TEST_WHILE_IDLE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.test-while-idle="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.time-between-eviction-runs-millis=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.time-between-eviction-runs-millis=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      time-between-eviction-runs-millis: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.time-between-eviction-runs-millis="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_TIME_BETWEEN_EVICTION_RUNS_MILLIS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.time-between-eviction-runs-millis="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.url=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.url=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      url: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.url="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_URL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.url="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.use-disposable-connection-facade=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.use-disposable-connection-facade=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      use-disposable-connection-facade: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.use-disposable-connection-facade="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_USE_DISPOSABLE_CONNECTION_FACADE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.use-disposable-connection-facade="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.use-equals=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.use-equals=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      use-equals: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.use-equals="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_USE_EQUALS="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.use-equals="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.use-lock=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.use-lock=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      use-lock: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.use-lock="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_USE_LOCK="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.use-lock="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.use-statement-facade=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.use-statement-facade=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      use-statement-facade: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.use-statement-facade="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_USE_STATEMENT_FACADE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.use-statement-facade="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.username=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.validation-interval=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.validation-interval=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      validation-interval: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.validation-interval="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_VALIDATION_INTERVAL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.validation-interval="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.validation-query=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.validation-query=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      validation-query: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.validation-query="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_VALIDATION_QUERY="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.validation-query="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.validation-query-timeout=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.validation-query-timeout=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      validation-query-timeout: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.validation-query-timeout="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_VALIDATION_QUERY_TIMEOUT="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.validation-query-timeout="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.tomcat.validator-class-name=

org.apache.tomcat.jdbc.pool.DataSource.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.tomcat.validator-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    tomcat: 
      validator-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.tomcat.validator-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TOMCAT_VALIDATOR_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.tomcat.validator-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.type=

Fully qualified name of the DataSource implementation to use. By default, a connection pool implementation is auto-detected from the classpath.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.type=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    type: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.type="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_TYPE="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.type="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.url=

JDBC URL of the database.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.url=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    url: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.url="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_URL="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.url="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.username=

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.username=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    username: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.username="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_USERNAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.username="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.xa.data-source-class-name=

XA datasource fully qualified name.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$Xa.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.xa.data-source-class-name=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    xa: 
      data-source-class-name: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.xa.data-source-class-name="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_XA_DATA_SOURCE_CLASS_NAME="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.xa.data-source-class-name="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.datasource.xa.properties=

Properties to pass to the XA data source.

org.springframework.boot.autoconfigure.jdbc.DataSourceProperties$Xa.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.datasource.xa.properties=...

CAS properties can be specified using the YAML syntax:

spring: 
  datasource: 
    xa: 
      properties: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.datasource.xa.properties="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_DATASOURCE_XA_PROPERTIES="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.datasource.xa.properties="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.cleanup-cron=0 * * * * *

Cron expression for expired session cleanup job.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.cleanup-cron=0 * * * * *

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      cleanup-cron: "0 * * * * *"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.cleanup-cron="0 * * * * *" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_CLEANUP_CRON="0 * * * * *"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.cleanup-cron="0 * * * * *"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.flush-mode=on-save

Sessions flush mode. Determines when session changes are written to the session store.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.flush-mode=on-save

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      flush-mode: "on-save"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.flush-mode="on-save" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_FLUSH_MODE="on-save"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.flush-mode="on-save"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.initialize-schema=embedded

Database schema initialization mode.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.initialize-schema=embedded

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      initialize-schema: "embedded"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.initialize-schema="embedded" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_INITIALIZE_SCHEMA="embedded"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.initialize-schema="embedded"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.platform=

Platform to use in initialization scripts if the @@platform@@ placeholder is used. Auto-detected by default.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.platform=...

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      platform: "..."

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.platform="..." -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_PLATFORM="..."

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.platform="..."

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.save-mode=on-set-attribute

Sessions save mode. Determines how session changes are tracked and saved to the session store.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.save-mode=on-set-attribute

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      save-mode: "on-set-attribute"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.save-mode="on-set-attribute" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_SAVE_MODE="on-set-attribute"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.save-mode="on-set-attribute"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/schema-@@platform@@.sql

Path to the SQL file to use to initialize the database schema.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/schema-@@platform@@.sql

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      schema: "classpath:org/springframework/session/jdbc/schema-@@platform@@.sql"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.schema="classpath:org/springframework/session/jdbc/schema-@@platform@@.sql" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_SCHEMA="classpath:org/springframework/session/jdbc/schema-@@platform@@.sql"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.schema="classpath:org/springframework/session/jdbc/schema-@@platform@@.sql"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

spring.session.jdbc.table-name=SPRING_SESSION

Name of the database table used to store sessions.

org.springframework.boot.autoconfigure.session.JdbcSessionProperties.

_{How can I configure this property?}

Configuration properties can be included and activated using the following strategies.

Note

CAS properties can be specified using the Java configuration property syntax in any and all .properties files:

spring.session.jdbc.table-name=SPRING_SESSION

CAS properties can be specified using the YAML syntax:

spring: 
  session: 
    jdbc: 
      table-name: "SPRING_SESSION"

Note that YAML is very specific about structure and indentation. Be sure to verify the correctness of the final result with your YAML validator of choice.

CAS properties can be passed to the CAS web application as system properties, when the application is launched:

java -Dspring.session.jdbc.table-name="SPRING_SESSION" -jar build/libs/cas.war

CAS properties can specified as system environment variables before the CAS web application is launched:

export SPRING_SESSION_JDBC_TABLE_NAME="SPRING_SESSION"

java -jar build/libs/cas.war

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

CAS properties can be passed to the CAS web application as command-line arguments, when the application is launched:

java -jar build/libs/cas.war --spring.session.jdbc.table-name="SPRING_SESSION"

The above example assumes that the CAS web application is packaged as cas.war with an embedded server container and can be found in the build/libs directory.

# Password of the certificate file.
# spring.datasource.azure.credential.client-certificate-password=

# Path of a PEM certificate file to use when performing service principal authentication with Azure.
# spring.datasource.azure.credential.client-certificate-path=

# Client ID to use when performing service principal authentication with Azure.
# spring.datasource.azure.credential.client-id=

# Client secret to use when performing service principal authentication with Azure.
# spring.datasource.azure.credential.client-secret=

# Whether to enable managed identity to authenticate with Azure.
# spring.datasource.azure.credential.managed-identity-enabled=false

# Password to use when performing username/password authentication with Azure.
# spring.datasource.azure.credential.password=

# Username to use when performing username/password authentication with Azure.
# spring.datasource.azure.credential.username=

# Whether to enable passwordless connections to Azure databases by using OAuth2 Microsoft Entra token credentials.
# spring.datasource.azure.passwordless-enabled=false

# Name of the Azure cloud to connect to.
# spring.datasource.azure.profile.cloud-type=

# The Microsoft Entra endpoint to connect to.
# spring.datasource.azure.profile.environment.active-directory-endpoint=

# Tenant ID for Azure resources.
# spring.datasource.azure.profile.tenant-id=

# 
# spring.datasource.continue-on-error=

# 
# spring.datasource.data=

# 
# spring.datasource.data-password=

# 
# spring.datasource.data-username=

# 
# spring.datasource.dbcp2.abandoned-usage-tracking=

# 
# spring.datasource.dbcp2.access-to-underlying-connection-allowed=

# 
# spring.datasource.dbcp2.auto-commit-on-return=

# 
# spring.datasource.dbcp2.cache-state=

# 
# spring.datasource.dbcp2.clear-statement-pool-on-return=

# 
# spring.datasource.dbcp2.connection-factory-class-name=

# 
# spring.datasource.dbcp2.connection-init-sqls=

# 
# spring.datasource.dbcp2.default-auto-commit=

# 
# spring.datasource.dbcp2.default-catalog=

# 
# spring.datasource.dbcp2.default-query-timeout=

# 
# spring.datasource.dbcp2.default-read-only=

# 
# spring.datasource.dbcp2.default-schema=

# 
# spring.datasource.dbcp2.default-transaction-isolation=

# 
# spring.datasource.dbcp2.disconnection-ignore-sql-codes=

# 
# spring.datasource.dbcp2.disconnection-sql-codes=

# 
# spring.datasource.dbcp2.driver-class-name=

# 
# spring.datasource.dbcp2.duration-between-eviction-runs=

# 
# spring.datasource.dbcp2.enable-auto-commit-on-return=

# 
# spring.datasource.dbcp2.eviction-policy-class-name=

# 
# spring.datasource.dbcp2.fast-fail-validation=

# 
# spring.datasource.dbcp2.initial-size=

# 
# spring.datasource.dbcp2.jmx-name=

# 
# spring.datasource.dbcp2.lifo=

# 
# spring.datasource.dbcp2.log-abandoned=

# 
# spring.datasource.dbcp2.log-expired-connections=

# 
# spring.datasource.dbcp2.login-timeout=

# 
# spring.datasource.dbcp2.max-conn-lifetime-millis=

# 
# spring.datasource.dbcp2.max-idle=

# 
# spring.datasource.dbcp2.max-open-prepared-statements=

# 
# spring.datasource.dbcp2.max-total=

# 
# spring.datasource.dbcp2.max-wait-millis=

# 
# spring.datasource.dbcp2.min-evictable-idle-time-millis=

# 
# spring.datasource.dbcp2.min-idle=

# 
# spring.datasource.dbcp2.num-tests-per-eviction-run=

# 
# spring.datasource.dbcp2.password=

# 
# spring.datasource.dbcp2.pool-prepared-statements=

# 
# spring.datasource.dbcp2.remove-abandoned-on-borrow=

# 
# spring.datasource.dbcp2.remove-abandoned-on-maintenance=

# 
# spring.datasource.dbcp2.remove-abandoned-timeout=

# 
# spring.datasource.dbcp2.rollback-on-return=

# 
# spring.datasource.dbcp2.soft-min-evictable-idle-time-millis=

# 
# spring.datasource.dbcp2.test-on-borrow=

# 
# spring.datasource.dbcp2.test-on-create=

# 
# spring.datasource.dbcp2.test-on-return=

# 
# spring.datasource.dbcp2.test-while-idle=

# 
# spring.datasource.dbcp2.time-between-eviction-runs-millis=

# 
# spring.datasource.dbcp2.url=

# 
# spring.datasource.dbcp2.username=

# 
# spring.datasource.dbcp2.validation-query=

# 
# spring.datasource.dbcp2.validation-query-timeout=

# Fully qualified name of the JDBC driver.
# spring.datasource.driver-class-name=

# Connection details for an embedded database.
# spring.datasource.embedded-database-connection=

# Whether to generate a random datasource name.
# spring.datasource.generate-unique-name=true

# 
# spring.datasource.hikari.allow-pool-suspension=

# 
# spring.datasource.hikari.auto-commit=

# 
# spring.datasource.hikari.catalog=

# 
# spring.datasource.hikari.connection-init-sql=

# 
# spring.datasource.hikari.connection-test-query=

# 
# spring.datasource.hikari.connection-timeout=

# 
# spring.datasource.hikari.data-source-class-name=

# 
# spring.datasource.hikari.data-source-j-n-d-i=

# 
# spring.datasource.hikari.data-source-properties=

# 
# spring.datasource.hikari.driver-class-name=

# 
# spring.datasource.hikari.exception-override-class-name=

# 
# spring.datasource.hikari.health-check-properties=

# 
# spring.datasource.hikari.idle-timeout=

# 
# spring.datasource.hikari.initialization-fail-timeout=

# 
# spring.datasource.hikari.isolate-internal-queries=

# 
# spring.datasource.hikari.jdbc-url=

# 
# spring.datasource.hikari.keepalive-time=

# 
# spring.datasource.hikari.leak-detection-threshold=

# 
# spring.datasource.hikari.login-timeout=

# 
# spring.datasource.hikari.max-lifetime=

# 
# spring.datasource.hikari.maximum-pool-size=

# 
# spring.datasource.hikari.minimum-idle=

# 
# spring.datasource.hikari.password=

# 
# spring.datasource.hikari.pool-name=

# 
# spring.datasource.hikari.read-only=

# 
# spring.datasource.hikari.register-mbeans=

# 
# spring.datasource.hikari.schema=

# 
# spring.datasource.hikari.transaction-isolation=

# 
# spring.datasource.hikari.username=

# 
# spring.datasource.hikari.validation-timeout=

# 
# spring.datasource.initialization-mode=

# Whether to enable JMX support (if provided by the underlying pool).
# spring.datasource.jmx-enabled=false

# JNDI location of the datasource.
# spring.datasource.jndi-name=

# Datasource name to use if "generate-unique-name" is false.
# spring.datasource.name=

# 
# spring.datasource.oracleucp.abandoned-connection-timeout=

# 
# spring.datasource.oracleucp.commit-on-connection-return=

# 
# spring.datasource.oracleucp.connection-factory-class-name=

# 
# spring.datasource.oracleucp.connection-factory-properties=

# 
# spring.datasource.oracleucp.connection-harvest-max-count=

# 
# spring.datasource.oracleucp.connection-harvest-trigger-count=

# 
# spring.datasource.oracleucp.connection-labeling-high-cost=

# 
# spring.datasource.oracleucp.connection-pool-name=

# 
# spring.datasource.oracleucp.connection-properties=

# 
# spring.datasource.oracleucp.connection-repurpose-threshold=

# 
# spring.datasource.oracleucp.connection-validation-timeout=

# 
# spring.datasource.oracleucp.connection-wait-duration=

# 
# spring.datasource.oracleucp.connection-wait-timeout=

# 
# spring.datasource.oracleucp.create-connection-in-borrow-thread=

# 
# spring.datasource.oracleucp.data-source-name=

# 
# spring.datasource.oracleucp.database-name=

# 
# spring.datasource.oracleucp.description=

# 
# spring.datasource.oracleucp.fast-connection-failover-enabled=

# 
# spring.datasource.oracleucp.high-cost-connection-reuse-threshold=

# 
# spring.datasource.oracleucp.inactive-connection-timeout=

# 
# spring.datasource.oracleucp.initial-pool-size=

# 
# spring.datasource.oracleucp.login-timeout=

# 
# spring.datasource.oracleucp.max-connection-reuse-count=

# 
# spring.datasource.oracleucp.max-connection-reuse-time=

# 
# spring.datasource.oracleucp.max-connections-per-shard=

# 
# spring.datasource.oracleucp.max-idle-time=

# 
# spring.datasource.oracleucp.max-pool-size=

# 
# spring.datasource.oracleucp.max-statements=

# 
# spring.datasource.oracleucp.min-idle=

# 
# spring.datasource.oracleucp.min-pool-size=

# 
# spring.datasource.oracleucp.network-protocol=

# 
# spring.datasource.oracleucp.o-n-s-configuration=

# 
# spring.datasource.oracleucp.pdb-roles=

# 
# spring.datasource.oracleucp.port-number=

# 
# spring.datasource.oracleucp.property-cycle=

# 
# spring.datasource.oracleucp.query-timeout=

# 
# spring.datasource.oracleucp.read-only-instance-allowed=

# 
# spring.datasource.oracleucp.role-name=

# 
# spring.datasource.oracleucp.s-q-l-for-validate-connection=

# 
# spring.datasource.oracleucp.seconds-to-trust-idle-connection=

# 
# spring.datasource.oracleucp.server-name=

# 
# spring.datasource.oracleucp.sharding-mode=

# 
# spring.datasource.oracleucp.time-to-live-connection-timeout=

# 
# spring.datasource.oracleucp.timeout-check-interval=

# 
# spring.datasource.oracleucp.u-r-l=

# 
# spring.datasource.oracleucp.user=

# 
# spring.datasource.oracleucp.validate-connection-on-borrow=

# Login password of the database.
# spring.datasource.password=

# 
# spring.datasource.platform=

# 
# spring.datasource.schema=

# 
# spring.datasource.schema-password=

# 
# spring.datasource.schema-username=

# 
# spring.datasource.separator=

# 
# spring.datasource.sql-script-encoding=

# 
# spring.datasource.tomcat.abandon-when-percentage-full=

# 
# spring.datasource.tomcat.access-to-underlying-connection-allowed=

# 
# spring.datasource.tomcat.alternate-username-allowed=

# 
# spring.datasource.tomcat.commit-on-return=

# 
# spring.datasource.tomcat.connection-properties=

# 
# spring.datasource.tomcat.data-source-j-n-d-i=

# 
# spring.datasource.tomcat.db-properties=

# 
# spring.datasource.tomcat.default-auto-commit=

# 
# spring.datasource.tomcat.default-catalog=

# 
# spring.datasource.tomcat.default-read-only=

# 
# spring.datasource.tomcat.default-transaction-isolation=

# 
# spring.datasource.tomcat.driver-class-name=

# 
# spring.datasource.tomcat.fair-queue=

# 
# spring.datasource.tomcat.ignore-exception-on-pre-load=

# 
# spring.datasource.tomcat.init-s-q-l=

# 
# spring.datasource.tomcat.initial-size=

# 
# spring.datasource.tomcat.jdbc-interceptors=

# 
# spring.datasource.tomcat.jmx-enabled=

# 
# spring.datasource.tomcat.log-abandoned=

# 
# spring.datasource.tomcat.log-validation-errors=

# 
# spring.datasource.tomcat.login-timeout=

# 
# spring.datasource.tomcat.max-active=

# 
# spring.datasource.tomcat.max-age=

# 
# spring.datasource.tomcat.max-idle=

# 
# spring.datasource.tomcat.max-wait=

# 
# spring.datasource.tomcat.min-evictable-idle-time-millis=

# 
# spring.datasource.tomcat.min-idle=

# 
# spring.datasource.tomcat.name=

# 
# spring.datasource.tomcat.num-tests-per-eviction-run=

# 
# spring.datasource.tomcat.password=

# 
# spring.datasource.tomcat.propagate-interrupt-state=

# 
# spring.datasource.tomcat.remove-abandoned=

# 
# spring.datasource.tomcat.remove-abandoned-timeout=

# 
# spring.datasource.tomcat.rollback-on-return=

# 
# spring.datasource.tomcat.suspect-timeout=

# 
# spring.datasource.tomcat.test-on-borrow=

# 
# spring.datasource.tomcat.test-on-connect=

# 
# spring.datasource.tomcat.test-on-return=

# 
# spring.datasource.tomcat.test-while-idle=

# 
# spring.datasource.tomcat.time-between-eviction-runs-millis=

# 
# spring.datasource.tomcat.url=

# 
# spring.datasource.tomcat.use-disposable-connection-facade=

# 
# spring.datasource.tomcat.use-equals=

# 
# spring.datasource.tomcat.use-lock=

# 
# spring.datasource.tomcat.use-statement-facade=

# 
# spring.datasource.tomcat.username=

# 
# spring.datasource.tomcat.validation-interval=

# 
# spring.datasource.tomcat.validation-query=

# 
# spring.datasource.tomcat.validation-query-timeout=

# 
# spring.datasource.tomcat.validator-class-name=

# Fully qualified name of the DataSource implementation to use.
# spring.datasource.type=

# JDBC URL of the database.
# spring.datasource.url=

# Login username of the database.
# spring.datasource.username=

# XA datasource fully qualified name.
# spring.datasource.xa.data-source-class-name=

# Properties to pass to the XA data source.
# spring.datasource.xa.properties=

# Cron expression for expired session cleanup job.
# spring.session.jdbc.cleanup-cron=0 * * * * *

# Sessions flush mode.
# spring.session.jdbc.flush-mode=on-save

# Database schema initialization mode.
# spring.session.jdbc.initialize-schema=embedded

# Platform to use in initialization scripts if the @@platform@@ placeholder is used.
# spring.session.jdbc.platform=

# Sessions save mode.
# spring.session.jdbc.save-mode=on-set-attribute

# Path to the SQL file to use to initialize the database schema.
# spring.session.jdbc.schema=classpath:org/springframework/session/jdbc/schema-@@platform@@.sql

# Name of the database table used to store sessions.
# spring.session.jdbc.table-name=SPRING_SESSION

Configuration Metadata

The collection of configuration properties listed in this section are automatically generated from the CAS source and components that contain the actual field definitions, types, descriptions, modules, etc. This metadata may not always be 100% accurate, or could be lacking details and sufficient explanations.

Be Selective

This section is meant as a guide only. Do NOT copy/paste the entire collection of settings into your CAS configuration; rather pick only the properties that you need. Do NOT enable settings unless you are certain of their purpose and do NOT copy settings into your configuration only to keep them as reference. All these ideas lead to upgrade headaches, maintenance nightmares and premature aging.

YAGNI

Note that for nearly ALL use cases, declaring and configuring properties listed here is sufficient. You should NOT have to explicitly massage a CAS XML/Java/etc configuration file to design an authentication handler, create attribute release policies, etc. CAS at runtime will auto-configure all required changes for you. If you are unsure about the meaning of a given CAS setting, do NOT turn it on without hesitation. Review the codebase or better yet, ask questions to clarify the intended behavior.

Naming Convention

Property names can be specified in very relaxed terms. For instance cas.someProperty, cas.some-property, cas.some_property are all valid names. While all forms are accepted by CAS, there are certain components (in CAS and other frameworks used) whose activation at runtime is conditional on a property value, where this property is required to have been specified in CAS configuration using kebab case. This is both true for properties that are owned by CAS as well as those that might be presented to the system via an external library or framework such as Spring Boot, etc.

Note

Settings and properties that are controlled by the CAS platform directly always begin with the prefix cas. All other settings are controlled and provided to CAS via other underlying frameworks and may have their own schemas and syntax. BE CAREFUL with the distinction. Unrecognized properties are rejected by CAS and/or frameworks upon which CAS depends. This means if you somehow misspell a property definition or fail to adhere to the dot-notation syntax and such, your setting is entirely refused by CAS and likely the feature it controls will never be activated in the way you intend.

Validation

Configuration properties are automatically validated on CAS startup to report issues with configuration binding, especially if defined CAS settings cannot be recognized or validated by the configuration schema. Additional validation processes are also handled via Configuration Metadata and property migrations applied automatically on startup by Spring Boot and family.

Indexed Settings

CAS settings able to accept multiple values are typically documented with an index, such as cas.some.setting[0]=value. The index [0] is meant to be incremented by the adopter to allow for distinct multiple configuration blocks.