It is related to #12 but not addresses it completely.
@stuartwdouglas, I had to move a restartRequired check out of the if (closeables != null) because there are 2 tests in development which use DevServices, SpnegoAuthenticationTestCase and now SpnegoAuthenticationDevModeTestCase - the 2nd one uses a different configuration but by the time it starts the closeables created by SpnegoAuthenticationTestCase is null but since java.security.krb5.conf set by SpnegoAuthenticationTestCase is still around, the new container is not started and SpnegoAuthenticationDevModeTestCase fails.
But now, since the static captured configuration keeps SpnegoAuthenticationTestCase 's one - it is possible to detect a restart is required, and thus, despite the system property pointing to the config file is already being set, the container is starting.
the Kerberos configuration contains QUARKUS.IO but KerberosIdentityProvider will attempt to use HTTP/localhost@QUARKUSDEV.IO - 401, and next after replacing QUARKUSDEV.IO with QUARKUS.IO only the Quarkus endpoint is restarted but not the dev services container (since the dev services properties remain unchanged), so all works fine in the end and it is 200.
then, after replacing QUARKUSDEV.IO with QUARKUS.IO, the dev services container is also restarted, new Kerberos config with a different realm is created and I suspect the system properties are not helping as it looks like either the client or server is caching something. But as far simulating the failures is concerned it does not really matter if the devservices container is restarted or not, so it is not a big problem
It is related to #12 but not addresses it completely.
@stuartwdouglas, I had to move a
restartRequiredcheck out of theif (closeables != null)because there are 2 tests indevelopmentwhich useDevServices,SpnegoAuthenticationTestCaseand nowSpnegoAuthenticationDevModeTestCase- the 2nd one uses a different configuration but by the time it starts thecloseablescreated bySpnegoAuthenticationTestCaseis null but sincejava.security.krb5.confset bySpnegoAuthenticationTestCaseis still around, the new container is not started andSpnegoAuthenticationDevModeTestCasefails.But now, since the static captured configuration keeps
SpnegoAuthenticationTestCase's one - it is possible to detect a restart is required, and thus, despite the system property pointing to the config file is already being set, the container is starting.Note the actual test works because with
the Kerberos configuration contains
QUARKUS.IObutKerberosIdentityProviderwill attempt to useHTTP/localhost@QUARKUSDEV.IO-401, and next after replacingQUARKUSDEV.IOwithQUARKUS.IOonly the Quarkus endpoint is restarted but not the dev services container (since the dev services properties remain unchanged), so all works fine in the end and it is200.But if I do
then, after replacing
QUARKUSDEV.IOwithQUARKUS.IO, the dev services container is also restarted, new Kerberos config with a different realm is created and I suspect the system properties are not helping as it looks like either the client or server is caching something. But as far simulating the failures is concerned it does not really matter if the devservices container is restarted or not, so it is not a big problem