When LTPA/SSL updates were made across OpenLiberty, it exposed some behaviour issues inherent within the following FATs:
com.ibm.ws.security.oidc.client_fat.1
com.ibm.ws.security.saml.sso_fat.2
com.ibm.ws.security.oidc.client_fat.2
com.ibm.ws.security.saml.sso_fat.1
These FATs use dev/com.ibm.ws.security.fat.common/src/com/ibm/ws/security/fat/common/TestServer.java as their server wrapper as it adds more functionality around a LibertyServer instance.
The behaviour is that when we update the server configuration. we do this to a live server, we don't stop, change config restart. Some of the config changes will cause the SSL endpoint to stop and restart, however most don't, but for every config update we check to see if the SSL endpoint has restarted. The way this is check via waitForStringInLogUsingMark results in a Timed out message in the logs and if we get >10 of those during the running of a test class we report an error for the class.
#35182 was created to mitigate this behaviour by stopping the initial wait for SSL endpoint to be shutdown, so we went from 10+ in that class to 2 where the configuration is updated such that the endpoint stops, but it does not restart as the config is bad which then increases the time to run the test as the initial check is 500ms, while the waiting for the endpoint to restart is 120 seconds.
We need to update the tests so they indicate based on their behaviour whether the endpoint should be stopped and/or endpoint started again. the default behaviour should be that no restart is checked for
When LTPA/SSL updates were made across OpenLiberty, it exposed some behaviour issues inherent within the following FATs:
com.ibm.ws.security.oidc.client_fat.1
com.ibm.ws.security.saml.sso_fat.2
com.ibm.ws.security.oidc.client_fat.2
com.ibm.ws.security.saml.sso_fat.1
These FATs use
dev/com.ibm.ws.security.fat.common/src/com/ibm/ws/security/fat/common/TestServer.javaas their server wrapper as it adds more functionality around aLibertyServerinstance.The behaviour is that when we update the server configuration. we do this to a live server, we don't stop, change config restart. Some of the config changes will cause the SSL endpoint to stop and restart, however most don't, but for every config update we check to see if the SSL endpoint has restarted. The way this is check via
waitForStringInLogUsingMarkresults in aTimed outmessage in the logs and if we get >10 of those during the running of a test class we report an error for the class.#35182 was created to mitigate this behaviour by stopping the initial wait for SSL endpoint to be shutdown, so we went from 10+ in that class to 2 where the configuration is updated such that the endpoint stops, but it does not restart as the config is bad which then increases the time to run the test as the initial check is 500ms, while the waiting for the endpoint to restart is 120 seconds.
We need to update the tests so they indicate based on their behaviour whether the endpoint should be stopped and/or endpoint started again. the default behaviour should be that no restart is checked for