How can I see the "merged" server.xml that the runtime sees after all relevant config is combined according to Liberty precedence rules?
My project's server.xml has a number of includes and potentially some configDropins files adding to the original server.xml, with build logic copying different sources into place.
<server>
<include location="dev.xml" optional="true"/>
<include location="common.xml" />
<!-- ... -->
</server>
/target/liberty/wlp/usr/servers/defaultServer/server.xml
/target/liberty/wlp/usr/servers/defaultServer/configDropins/defaults/quick-start-security.xml
/target/liberty/wlp/usr/servers/defaultServer/configDropins/overrides/liberty-plugin-variable-config.xml
E.g. take a config element like applicationMonitor.
<applicationMonitor dropinsEnabled="false" updateTrigger="mbean"/>
If this element appears more than once across the various config files with different attribute values in each, how can I see the final "merged" value?
Use the config
REST endpoint provided by the Liberty restConnector-2.0
feature.
restConnector-2.0
feature.<server description="my server">
<featureManager>
<feature>restConnector-2.0</feature>
</featureManager>
</server>
<server description="my server">
<quickStartSecurity userName="bob" userPassword="bobpassword" />
<keyStore id="defaultKeyStore" password="keystorePassword"/>
</server>
Start the server and access the https://<host>:<port>/ibm/api/config
endpoint, e.g.: https://localhost:9443/ibm/api/config and login with the configured user:password = bob:bobpassword
.
Look at the JSON response, e.g. for applicationMonitor
something like:
{
"configElementName": "applicationMonitor",
"dropins": "dropins",
"dropinsEnabled": false,
"pollingRate": 500,
"updateTrigger": "mbean"
},
See the restConnector-2.0 feature documentation for additional options.
Not only will you see config elements explicitly configured in server.xml and the includes and configDropins, but you might also see additional elements like <batchPersistence>
not explicitly configured anywhere. These might come from the runtime Config Admin service, which can provides defaults at an "inner" layer, relevant to the overall configuration story.
For more information, see the article: https://openliberty.io/docs/latest/validating-server-connections.html
This article also describes how to use the config
API to view the values of individual config elements, and also how to do "validation" of certain elements, e.g. a "test connection" of a JDBC dataSource
.