Experimental Providers
Providers annotated with @Experimental are registered in CDI but blocked during
configuration validation unless the controlling vault entry is set to "true" for the
organization. This lets new providers ship in the codebase without being usable in
production until explicitly enabled.
Vault key​
Every @Experimental annotation carries a vault key. The default key is
ALLOW_EXPERIMENTAL_CUSTOM_CLASSES. Providers that need their own toggle use a
dedicated key:
// default key
@Experimental
public class MyProvider extends SomeProvider { ... }
// dedicated key
@Experimental("ENABLE_DOCUSIGN_V2")
public class DocuSignV2Provider extends SigningProvider { ... }
Set the vault entry for an organization to "true" to enable the provider:
| vault_key | vault_value | effect |
|---|---|---|
| ALLOW_EXPERIMENTAL_CUSTOM_CLASSES | true | provider enabled |
| ALLOW_EXPERIMENTAL_CUSTOM_CLASSES | false | provider blocked |
| (missing) | - | provider blocked |
Scenarios​
Provider not yet enabled​
No vault entry exists, or it is set to "false". Configuration validation rejects the
provider and returns:
{ClassName} is an experimental feature (vault key: '{VAULT_KEY}'). Experimental providers should not be used in production configurations. Set vault entry '{VAULT_KEY}' to 'true' to enable runtime access.
Provider already enabled​
The vault entry exists and its value is "true". Validation passes and the provider
can be used normally. The behavior is identical to a non-experimental provider for the
enabling organization.
Vault key removed​
The vault entry is deleted. The system defaults to false - same result as "not yet
enabled". The provider is immediately blocked for that organization on the next
validation run; no restart is required because vault entries are cache-invalidated.
Validation scope​
Both the provider class and its settings class are checked independently.
If either is annotated with @Experimental and the vault key is not enabled, the
configuration is rejected.
Audit logging​
Every time an experimental provider is instantiated or its configuration is validated,
a CONFIGURATION / EXPERIMENTAL log entry is inserted regardless of whether the
vault entry is enabled. This creates a permanent audit trail of experimental feature
usage per organization.