+
Skip to content

Make @EnableFeature to handle the case with added provider of currently non-used SPI #36425

@mposolda

Description

@mposolda

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 (including ClientTypeSPI) 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:

  1. 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...

  2. Update only testsuite to make sure that @EnableFeature is able to add new SPIs as well into the DefaultKeycloakSessionFactory.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

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    点击 这是indexloc提供的php浏览器服务,不要输入任何密码和下载