KB-2353 Webapp pod fails to start due to incorrect data source password factory

pauline.delacruz — Wed, 08 Oct 2025 18:50:45 GMT

Current Revision posted to Appian Knowledge Base by pauline.delacruz on 10/8/2025 6:50:45 PM

The webapp pod requires properly configured data source credentials to be able to communicate with the RDBMS. In Appian on Kubernetes (AoK), these credentials are often contained within a Kubernetes secret, but may also be specified in plaintext within the CR. webapp makes use of a data source factory in order to authenticate and create connections with the primary data source RDBMS.

Customers on Legacy Self-Managed Appian (Windows or Linux) typically encode data source passwords using the configure script as recommended in documentation, however the default data source factory for AoK does not expect an encoded password. This difference can sometimes prevent the webapp pod from coming up the first time the environment is configured, especially common for those customers who have migrated to AoK from Legacy Self-Managed using Appian's AoK migration tool.

Symptoms

The webapp pod refuses to start, as it is waiting for the primary data source RDBMS to be healthy. The following error traces may be present in the pod logs:

YYYY-MM-DD HH:MM:SS,mmm [wait-for-component] ERROR com.appiancorp.common.startup.healthcheck.PrimaryRdbmsHealthCheck - javax.naming.NamingException: Unexpected exception resolving reference with name [AppianDS] [Root exception is java.lang.IllegalArgumentException: Illegal base64 character 21]
YYYY-MM-DD HH:MM:SS,mmm [wait-for-component] INFO com.appiancorp.common.startup.WaitForStatefulComponents - Waiting for Appian component Primary datasource RDBMS to be healthy...
YYYY-MM-DD HH:MM:SS WARNING [wait-for-component] org.apache.naming.NamingContext.lookup Unexpected exception resolving reference with name [AppianDS]
 java.lang.IllegalArgumentException: Illegal base64 character 21
 at java.base/java.util.Base64$Decoder.decode0(Base64.java:848)
 at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
 at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
 at com.appiancorp.tomcat.encoding.EncodingCryptographer.decodePassword(EncodingCryptographer.java:25)
 at com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory.getObjectInstance(EncodedPasswordDataSourceFactory.java:44)

Additionally, the following field is set within the Appian CR:

spec:
  webapp:
    dataSources:
      primary:
        factory: com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory

Cause

The Appian CR is configured to use the com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory factory for the primary data source, which expects a password that has been encoded using Appian's configure script. However, the password specified (which may be contained within a secret or specified within the CR) is not encoded. As a result, the webapp pod is not able to authenticate with the primary data source using the specified password.

Action

Edit the Appian CR as so that webapp expects a non-encoded password by changing the factory to org.apache.tomcat.jdbc.pool.DataSourceFactory. This is the default factory for Appian on Kubernetes:

spec:
  webapp:
    dataSources:
      primary:
        factory: org.apache.tomcat.jdbc.pool.DataSourceFactory

Affected Versions

This article applies to all versions of Appian on Kubernetes.

Last Reviewed: August 2025

Tags: database, infrastructure, Kubernetes

[DRAFT] KB-XXXX Webapp pod fails to start due to incorrect data source password factory

pauline.delacruz — Wed, 13 Aug 2025 19:29:53 GMT

Revision 6 posted to Appian Knowledge Base by pauline.delacruz on 8/13/2025 7:29:53 PM

Symptoms

The webapp pod refuses to start, as it is waiting for the primary data source RDBMS to be healthy. The following error traces may be present in the pod logs:

YYYY-MM-DD HH:MM:SS,mmm [wait-for-component] ERROR com.appiancorp.common.startup.healthcheck.PrimaryRdbmsHealthCheck - javax.naming.NamingException: Unexpected exception resolving reference with name [AppianDS] [Root exception is java.lang.IllegalArgumentException: Illegal base64 character 21]
YYYY-MM-DD HH:MM:SS,mmm [wait-for-component] INFO com.appiancorp.common.startup.WaitForStatefulComponents - Waiting for Appian component Primary datasource RDBMS to be healthy...
YYYY-MM-DD HH:MM:SS WARNING [wait-for-component] org.apache.naming.NamingContext.lookup Unexpected exception resolving reference with name [AppianDS]
 java.lang.IllegalArgumentException: Illegal base64 character 21
 at java.base/java.util.Base64$Decoder.decode0(Base64.java:848)
 at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
 at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
 at com.appiancorp.tomcat.encoding.EncodingCryptographer.decodePassword(EncodingCryptographer.java:25)
 at com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory.getObjectInstance(EncodedPasswordDataSourceFactory.java:44)

Additionally, the following field is set within the Appian CR:

spec:
  webapp:
    dataSources:
      primary:
        factory: com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory

Cause

Action

Edit the Appian CR as so that webapp expects a non-encoded password by changing the factory to org.apache.tomcat.jdbc.pool.DataSourceFactory. This is the default factory for Appian on Kubernetes:

spec:
  webapp:
    dataSources:
      primary:
        factory: org.apache.tomcat.jdbc.pool.DataSourceFactory

Affected Versions

This article applies to all versions of Appian on Kubernetes.

Last Reviewed: August 2025

Tags: database, infrastructure, Kubernetes

[DRAFT] KB-XXXX Webapp pod fails to start due to incorrect data source password factory

dan.endean — Fri, 08 Aug 2025 16:16:32 GMT

Revision 5 posted to Appian Knowledge Base by dan.endean on 8/8/2025 4:16:32 PM

The webapp pod requires properly configured data source credentials to be able to communicate with the RDBMS. In Appian on Kubernetes, these credentials are often contained within a Kubernetes secret, but may also be specified in plaintext within the CR. webapp makes use of a data source factory in order to authenticate and create connections with the primary data source RDBMS.

Symptoms

The webapp pod refuses to start, as it is waiting for the primary data source RDBMS to be healthy. The following error traces may be present in the pod logs:

2025-08-08 15:52:12,633 [wait-for-component] ERROR com.appiancorp.common.startup.healthcheck.PrimaryRdbmsHealthCheck - javax.naming.NamingException: Unexpected exception resolving reference with name [AppianDS] [Root exception is java.lang.IllegalArgumentException: Illegal base64 character 21]
2025-08-08 15:51:52,626 [wait-for-component] INFO  com.appiancorp.common.startup.WaitForStatefulComponents - Waiting for Appian component Primary datasource RDBMS to be healthy...
2025-08-08 15:51:57 WARNING [wait-for-component] org.apache.naming.NamingContext.lookup Unexpected exception resolving reference with name [AppianDS]
        java.lang.IllegalArgumentException: Illegal base64 character 21
                at java.base/java.util.Base64$Decoder.decode0(Base64.java:848)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
                at com.appiancorp.tomcat.encoding.EncodingCryptographer.decodePassword(EncodingCryptographer.java:25)
                at com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory.getObjectInstance(EncodedPasswordDataSourceFactory.java:44)

Additionally, the the following field is set within the Appian CR:

spec:
  webapp:
    dataSources:
      primary:
        factory: com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory

Cause

Action

Edit the Appian CR as so that webapp expects a non-encoded password by changing the factory to org.apache.tomcat.jdbc.pool.DataSourceFactory. This is the default factory for Appian on Kubernetes:

spec:
  webapp:
    dataSources:
      primary:
        factory: org.apache.tomcat.jdbc.pool.DataSourceFactory

Affected Versions

This article applies to all versions of Appian on Kubernetes.

Last Reviewed: August 2025

[DRAFT] KB-XXXX Webapp pod fails to start due to invalid data source password

dan.endean — Fri, 08 Aug 2025 16:14:54 GMT

Revision 4 posted to Appian Knowledge Base by dan.endean on 8/8/2025 4:14:54 PM

The webapp pod requires properly configured data source credentials to be able to communicate with the RDBMS. In Appian on Kubernetes, these credentials are often contained within a Kubernetes secret, but may also be specified in plaintext within the CR. webapp makes use of a data source factory in order to authenticate and create connections with the primary data source RDBMS.

Customers on Legacy Self-Managed Appian (Windows or Linux) typically encode data source passwords using the configure script as recommended in documentation, however the default data source factory for AoK does not expect an encoded password. This difference can sometimes prevent the webapp pod from coming up the first time the environment is configured, especially common for those customers who have migrated to AoK from Legacy Self-Managed using Appian's AoK migration tool.

Symptoms

The webapp pod refuses to start, as it is waiting for the primary data source RDBMS to be healthy. The following error traces may be present in the pod logs:

2025-08-08 15:52:12,633 [wait-for-component] ERROR com.appiancorp.common.startup.healthcheck.PrimaryRdbmsHealthCheck - javax.naming.NamingException: Unexpected exception resolving reference with name [AppianDS] [Root exception is java.lang.IllegalArgumentException: Illegal base64 character 21]
2025-08-08 15:51:52,626 [wait-for-component] INFO  com.appiancorp.common.startup.WaitForStatefulComponents - Waiting for Appian component Primary datasource RDBMS to be healthy...
2025-08-08 15:51:57 WARNING [wait-for-component] org.apache.naming.NamingContext.lookup Unexpected exception resolving reference with name [AppianDS]
        java.lang.IllegalArgumentException: Illegal base64 character 21
                at java.base/java.util.Base64$Decoder.decode0(Base64.java:848)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
                at com.appiancorp.tomcat.encoding.EncodingCryptographer.decodePassword(EncodingCryptographer.java:25)
                at com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory.getObjectInstance(EncodedPasswordDataSourceFactory.java:44)

Additionally, the the following field is set within the Appian CR:

spec:
  webapp:
    dataSources:
      primary:
        factory: com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory

Cause

The Appian CR is configured to use the com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory factory for the primary data source, which expects a password that has been encoded using Appian's configure script. However, the password specified (which may be contained within a secret or specified within the CR) is not encoded. As a result, the webapp pod is not able to authenticate with the primary data source using the specified password.

Action

Edit the Appian CR as so that webapp expects a non-encoded password by changing the factory to org.apache.tomcat.jdbc.pool.DataSourceFactory. This is the default factory for Appian on Kubernetes:

spec:
  webapp:
    dataSources:
      primary:
        factory: org.apache.tomcat.jdbc.pool.DataSourceFactory

Affected Versions

This article applies to all versions of Appian on Kubernetes.

Last Reviewed: August 2025

[DRAFT] KB-XXXX Webapp pod fails to start due to invalid data source password

dan.endean — Fri, 08 Aug 2025 16:08:37 GMT

Revision 3 posted to Appian Knowledge Base by dan.endean on 8/8/2025 4:08:37 PM

Symptoms

The webapp pod refuses to start, as it is waiting for the Primary datasource RDBMS to be healthy. The following error traces may be present in the pod logs:

2025-08-08 15:52:12,633 [wait-for-component] ERROR com.appiancorp.common.startup.healthcheck.PrimaryRdbmsHealthCheck - javax.naming.NamingException: Unexpected exception resolving reference with name [AppianDS] [Root exception is java.lang.IllegalArgumentException: Illegal base64 character 21]
2025-08-08 15:51:52,626 [wait-for-component] INFO  com.appiancorp.common.startup.WaitForStatefulComponents - Waiting for Appian component Primary datasource RDBMS to be healthy...
2025-08-08 15:51:57 WARNING [wait-for-component] org.apache.naming.NamingContext.lookup Unexpected exception resolving reference with name [AppianDS]
        java.lang.IllegalArgumentException: Illegal base64 character 21
                at java.base/java.util.Base64$Decoder.decode0(Base64.java:848)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:566)
                at java.base/java.util.Base64$Decoder.decode(Base64.java:589)
                at com.appiancorp.tomcat.encoding.EncodingCryptographer.decodePassword(EncodingCryptographer.java:25)
                at com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory.getObjectInstance(EncodedPasswordDataSourceFactory.java:44)

Additionally, the the following field is set within the Appian CR:

spec:
  webapp:
    dataSources:
      primary:
        factory: com.appiancorp.tomcat.datasource.EncodedPasswordDataSourceFactory

Cause

Action

Edit the Appian CR as so that webapp expects a non-encoded password. This is the default factory for Appian on Kubernetes:

spec:
  webapp:
    dataSources:
      primary:
        factory: org.apache.tomcat.jdbc.pool.DataSourceFactory

Affected Versions

This article applies to all versions of Appian on Kubernetes.

Last Reviewed: August 2025

[DRAFT] KB-XXXX Webapp pod fails to start due to invalid data source password

dan.endean — Thu, 07 Aug 2025 20:23:17 GMT

Revision 2 posted to Appian Knowledge Base by dan.endean on 8/7/2025 8:23:17 PM

Symptoms

The webapp pod refuses to start. The following error traces are present in the pod logs:

Cause

This section is required for this template. When writing a cause for a particular article, ensure the following is taken into consideration:

The cause is concise and does not disclose more information than absolutely necessary.
The cause does not share any Appian source code. Source code for plugins/shared components are fine.
If this is an issue outside of the Appian product and the third-party vendor included documentation referencing the bug, provide their documentation for reference.

For any enhancements/defects, use one of the following as applicable:

This issue has been reported to the Appian Product Team. The reference number for this issue is AN-XXXXX.
This product use case has been logged to the Appian Product Team for consideration to add this functionality in the product. Kindly note it is not Appian Support’s policy to disclose how or when a product use case will be implemented.
This issue has been hotfixed via AN-XXXXX in Appian X.X.
This issue has been hotfixed via AN-XXXXX in Appian X.X to X.X.
This use case has been incorporated in Appian X.X.
This use case has been incorporated in Appian X.X to X.X.

When logging a product defect, ensure you use the known issues tag as well as the open issues or fixed issues tag, depending if the issue is fixed or not.

If no cause is known and this is not something Engineering can reproduce/needs to know about, then say “The root cause of this issue is currently unknown.” If you use that as your cause, then a valid action must be present.

Action

This section is required for this template and contains the steps to resolve the issue. If an issue in an article is solved by a hotfix and/or major version of Appian, use the following language to indicate that:

Apply the latest hotfix to your Appian installation.
Upgrade to the latest version of Appian.
Apply the latest hotfix to your Appian installation or upgrade to the latest version of Appian.

If there is a product issue with Engineering that is open and a workaround for that issue exists, include it in the Action section until the fix is available. After the fix is made available, use that as a workaround instead.

Otherwise, the content in this section should wholly solve a customer’s issue without producing any undesirable side effects. If there is at least one valid action that doesn’t cause undesirable side effects, all other actions with negative side effects should go in the Workaround section.

If there is no action or workaround that resolves the issue, use the following language:

There is no action or workaround currently available for this issue. If you are facing this issue, please open a support case with Appian.

Workaround

This section is optional and should only be used as an alternative action if there is a massive technical debt associated with performing the action in the above section for customers (such as upgrading). It can also be used if there is a solution to the issue in the article but is more inconvenient to implement or it causes other undesirable behavior and wouldn’t warrant being an action.

Affected Versions

This section includes any relevant version information for Appian or other third/party configurations. Some examples of valid affected versions are as follows:

This article applies to all versions of Appian.
This article applies to all self-managed versions of Appian.
This article applies to all versions of Appian Cloud.
This article applies to Appian 7.11 and later.
This article applies to Appian 16.2 and earlier.
This article applies to Appian 7.11 and 16.1.
This article applies to Appian 16.1, 16.2, and 16.3.
This article applies to self-managed Appian 19.3 and earlier.
This article applies to all versions of Appian from Appian 7.10 to Appian 16.2.
This article applies to all versions of Appian using JBoss EAP 6.4.9 as an application server and Internet Explorer 9 as a web browser.

Last Reviewed: Month YYYY

[DRAFT] KB-XXXX Webapp pod fails to start due to invalid data source password

dan.endean — Mon, 30 Jun 2025 19:37:50 GMT

Revision 1 posted to Appian Knowledge Base by dan.endean on 6/30/2025 7:37:50 PM

Drafting...