OpenFeature

At the component level, you set general and shared configurations that are, then, inherited by the endpoints. It is the highest configuration level.

For example, a component may have security settings, credentials for authentication, urls for network connection and so forth.

Some components only have a few options, and others may have many. Because components typically have pre-configured defaults that are commonly used, then you may often only need to configure a few options on a component; or none at all.

You can configure components using:

You usually spend more time setting up endpoints because they have many options. These options help you customize what you want the endpoint to do. The options are also categorized into whether the endpoint is used as a consumer (from), as a producer (to), or both.

Configuring endpoints is most often done directly in the endpoint URI as path and query parameters. You can also use the Endpoint DSL and DataFormat DSL as a type safe way of configuring endpoints and data formats in Java.

A good practice when configuring options is to use Property Placeholders.

Property placeholders provide a few benefits:

The following two sections list all the options, firstly for the component followed by the endpoint.

A boolean flag enables or disables a feature. The flag definition declares two variants (on / off) mapping to true / false:

The route evaluates the flag and stores the result in an exchange property so the original message body is preserved:

Boolean evaluation is the default (evaluationType is unset and defaultValue defaults to "false").

A variant flag returns a string value rather than a boolean. Set evaluationType to variant — either as a path parameter or query parameter:

The resultProperty option stores the result in an exchange property instead of replacing the message body.

A fractional targeting rule splits traffic across variants by percentage. The provider uses the targeting key to assign each request deterministically to a variant — the same targeting key always gets the same variant.

The route passes a targeting key so each order ID is consistently assigned to the same variant:

Without a targeting key, fractional evaluation may fall back to a random assignment or the default variant, depending on the provider.

A targeted rule uses evaluation context attributes to decide which variant to return. In this example, enterprise and VIP customer orders get v2 while all others get v1:

The route stores the result in an exchange property and routes dynamically:

The evaluation context is provided via a header — useful when the message body carries business data:

Alternatively, enable contextFromBody=true to use a Map body as the evaluation context:

For a remote flagd service, configure host (and optionally port, tls, certPath, and deadline):

OpenFeature is a vendor-neutral specification. Beyond the built-in flagd provider, the OpenFeature community maintains provider implementations for many feature flag services. Examples include LaunchDarkly, Split, Flagsmith, Flipt, ConfigCat, GrowthBook, and AWS AppConfig among others. See the OpenFeature ecosystem page for the full list of available Java providers.

To use a custom provider, add the provider’s Maven dependency to your project and register it as a bean. For example, the env-var provider resolves flag values from environment variables:

Register the provider as a bean named flags (the default lookup name) or with a custom name:

Routes then use the provider without any additional configuration:

Or reference a named provider bean explicitly:

The OpenFeature SDK ships with an InMemoryProvider that requires no external service and no additional dependency. Register it as a bean named flags to make it the default provider, or reference it explicitly with the provider option.

Routes then use the provider without any additional configuration:

For boolean predicates in EIP constructs, use the OpenFeature language: