@Value Framework-Internal Adoption

This page documents the framework-internal sites that read configuration through the @Value seam (introduced in 10.0.0). It is a reference for users who:

• Used to import the deleted CallLogger.SP_xxx constants directly.
• Want to know which framework defaults are now @Value-driven (and therefore overridable through the standard Settings precedence chain — system properties, environment variables, registered PropertySources, and Settings.setGlobal(...)).

Migration outcome

In 10.0.0, the following framework-internal config readers were rewritten on top of the @Value annotation and BeanInstantiator:

Class	Field / Property	Inline expression
RestContext	env-driven defaults for uriAuthority, uriContext (Optional<String>-typed; null-vs-empty preserved)	${RestContext.uriAuthority} / ${RestContext.uriContext}
RestOpContext	env-driven defaults for defaultCharset, maxInput	${RestContext.defaultCharset:UTF-8} / ${RestContext.maxInput:100000000}
VersionProvider.Builder	javaVersionDefault	${java.version:Unknown}
Microservice.Builder	juneau.workingDir	${juneau.workingDir} (via @Inject initializer)
JettyServerComponent	availablePort, juneau.serverPort	${availablePort} / ${juneau.serverPort} (Optional<String> fields)
JwtTokenValidator.Builder	jwksCacheTtl	${juneau.jwt.jwksCacheTtl:PT5M}
JwtTokenValidator.Builder	jwksEagerRefreshOnKidMiss	${juneau.jwt.jwksEagerRefreshOnKidMiss:true}
JwtTokenValidator.Builder	jwksEagerRefreshCooldown	${juneau.jwt.jwksEagerRefreshCooldown:PT10S}
BctConfiguration.Defaults	sortMaps, sortCollections	concat-form: ${" + BCT_SORT_MAPS + ":false} / ${" + BCT_SORT_COLLECTIONS + ":false}

Every one of these sites used to call env(...) or System.getProperty(...) directly. The new flow routes through BeanInstantiator and inherits the standard Settings lookup chain documented in @Value Annotation Basics.

10.0.0 update — most RestContext.* sites moved to @ConfigProperties

The 14 other RestContext.*-prefixed sites (allowedHeaderParams, allowedMethodHeaders, allowedMethodParams, disableContentParam, renderResponseStackTraces, problemDetails, virtualThreads, responseTraceparent, mdcAsyncPropagation, eagerInit, lazyChildren, clientVersionHeader, uriRelativity, uriResolution) were collapsed in 10.0.0 into a single @ConfigProperties-bound bean, RestContextProperties — see @ConfigProperties Annotation Basics and the RestContext topic page. Only uriAuthority and uriContext (the table rows above) remain plain @Value fields on RestContext. (The REST debug/logging redesign separately removed RestContext.debugDefault entirely — see Logging / Debugging — so it is no longer one of these sites at all.)

Static-factory pattern

The four builders that did not previously flow through BeanInstantiator now do, via a small static factory that hands the builder off to BeanInstantiator.of(Builder.class).run():

public static Builder create(BeanStore beanStore) {
    return BeanInstantiator.of(Builder.class, beanStore).run();
}

Builders affected: VersionProvider, Microservice, JwtTokenValidator, plus the static-utility nested class BctConfiguration.Defaults. The BctConfiguration.BCT_SORT_MAPS and BCT_SORT_COLLECTIONS constants on that class were kept — they are part of the public BCT API and have external production consumers; they're now referenced from @Value annotations via concat form.

For classes that are not constructed through BeanInstantiator (because they're built by the framework — RestContext, RestOpContext, JettyServerComponent), the constructor / lifecycle hook calls ClassInfo.of(this).inject(this, beanStore) after the bean store is populated, which performs the same @Value field injection on the existing instance.

What this does not change

The mergeReplacedStringAttribute precedence inside RestContext — where @Rest annotation values from the resource hierarchy override the env-driven default if non-blank — is unchanged. The DefaultConfig class (whose @Rest(...) defaults pull from $S{j.<name>, $E{J_<NAME>,<fallback>}} SVL chains) still wins over the new @Value field for properties whose DefaultConfig fallback is non-blank. The @Value-driven default only takes effect in the same situations the previous env(...) default did.