-
Notifications
You must be signed in to change notification settings - Fork 7.7k
Description
Description
The @EnableFeature
annotation is used in the arquillian testsuite to dynamically enable some features for the particular test class or test method. The @EnableFeature
in most cases does not require server restart as it can dynamically deploy some providers, which implement EnvironmentDependentProviderFactory
and make sure that providers are enabled for the particular tests.
However there is the case when this does not work as expected. It can happen when deploying some provider, which implements SPI, which previously did not have any implementation. For example ClientTypeSPI
has single implementation DefaultClientTypeProviderFactory
, but this factory is implemented only when client-types
feature is enabled. So by default, the ClientTypeSPI
does not have any implementation available. The behaviour currently is:
- On Keycloak on undertow, the map
DefaultKeycloakSessionFactory.spis
initially contains all the available SPIs (includingClientTypeSPI
) after server start. - On Keycloak on quarkus, the map
DefaultKeycloakSessionFactory.spis
initially contains only the SPIs, which has at least one implementation available
The fact that ClientTypesSPI
(or any other similar SPI) is not available on the server initially makes the @EnableFeature
will not deploy the providers on quarkus. This means that some tests (like ClientTypesTest
or any OID4VCI tests and maybe more) require server restart.
Possible approaches to address this:
-
Have
DefaultKeycloakSessionFactory.spis
available on quarkus on startup as well to contains all available SPIs (not just those, which have at least one provider enabled). However I am not sure about the amount of changes... -
Update only testsuite to make sure that
@EnableFeature
is able to add new SPIs as well into theDefaultKeycloakSessionFactory.spis
map when deploying new providers after some feature is enabled
NOTE: I've faced this when doing some refactoring of token exchange ( #35504 ) and figured that after refactoring (which makes the TokenExchangeProvider not having any implementations available initially), the restart is always needed
Discussion
No response
Motivation
No response
Details
No response