You are currently reviewing an older revision of this page.
Symptom 1
- Login Page loads via https but static content does not load. Inspecting the page through a network capture reveals that static content response is coming from an undesired port.
Symptom 2
- Setting a Default Start Page on the 'User Start Pages' tab of the Admin Console yields the following error
The URL is invalid or has an incorrect base URL. The base URL must be https://FQDN:<INCORRECT_PORT>
Symptom 3
- Logging in yields a 401 error when hitting suite/tempo
Symptom 4
JBOSS fails to start with errors that point to data sources that do not exist in custom.properties, appian-ds.xml, nor standalone.xml.
A custom.properties file exists somewhere else on the server other than <APPIAN_HOME>/conf.
Apache commons-configuration PropertiesConfiguration will attempt to find a file specified by just the name with a call to ConfigurationUtils.locate which resolves in the following order:
AE_HOME/conf is on the classpath, so up until now we've been relying on getting to step #4. But both customers had stale versions of custom.properties laying around in the home directory of the user who started the appserver, so their sites were picking up the wrong file and quietly breaking.
Jboss could not start because the data sources defined in the custom.properties file in the user's home directory no longer existed in the ds.xml after updates were made to the ds.xml and the APPIAN_HOME custom.properties.
custom.properties with stale values in the user’s home directory. Jboss was overwriting the customer’s updates to the custom.properties in the APPIAN_HOME directory with these, so their expected changes were not taking affect.
Looking in the apache commons configuration code, when custom.properties is loaded we're just providing a file name, not a path. org.apache.commons.configuration.ConfigurationUtils.locate() is called to try to find the URL where that file exists. It searches in the following order:
1) directly from the URL (which it doesn't have)
2) base directory (which it doesn't have)
3) user's home directory if it can find one (which is what I think is getting picked up in both tickets I've seen)
4) classpath (which is what we want...will find it under AE_HOME/conf)
This is why when the file found in the user home directory is deleted and the appserver restarted things work fine...it gets to the classpath part of the search and finds it in conf.
Tag Patty Phonemany