shashank created CAMEL-25352:
--------------------------------
Summary: camel-main - CAMEL_COMPONENT_*, CAMEL_DATAFORMAT_* and
CAMEL_LANGUAGE_* environment variables are ignored, and a name that starts with
another one (NETTY_HTTP, SJMS2, JSONPATH, ...) is mapped to the shorter one
Key: CAMEL-25352
URL: https://issues.apache.org/jira/browse/CAMEL-25352
Project: Camel
Issue Type: Bug
Components: camel-main
Reporter: shashank
{{BaseMainSupport.autoConfigurationFromProperties}} gathers the ENV variables
that configure components, data formats and languages with
{code:java}
Map<String, String> env = MainHelper
.filterEnvVariables(new String[] { "camel.component.",
"camel.dataformat.", "camel.language." });
{code}
but {{MainHelper.filterEnvVariables}} upper-cases the name of every variable
and compares it with these lower-case, dotted prefixes
({{uk.startsWith(prefix)}}), so it never keeps a variable. The code after it
({{addComponentEnvVariables}}, {{addDataFormatEnvVariables}},
{{addLanguageEnvVariables}}), which maps {{CAMEL_COMPONENT_AWS2_S3_ACCESS_KEY}}
to {{camel.component.aws2-s3.access-key}} with the generated lists of known
names, never runs in production; {{MainHelperTest}} only exercises it with the
prefix {{CAMEL_COMPONENT_}}. As a result
{{CAMEL_COMPONENT_SEDA_QUEUE_SIZE=123}} neither sets the option nor overrules
{{camel.component.seda.queueSize=500}} from {{application.properties}},
although {{camel.main.autoConfigurationEnvironmentVariablesEnabled}} (default
true) "allows to overrule any configuration using an OS environment variable".
The same variables worked before CAMEL-16345 (Camel 3.9), which replaced
{{loadEnvironmentVariablesAsProperties("camel.component.", ...)}} (which
accepts {{CAMEL_COMPONENT_}} names) by {{filterEnvVariables}} but kept the
prefixes. Variables of {{camel.main.*}} ({{CAMEL_MAIN_*}}) are not affected
(they go through {{loadEnvironmentVariablesAsProperties}}). This concerns the
runtimes built on camel-main (Camel Main, Camel JBang, Camel Quarkus); with
Camel Spring Boot the same variables are applied by Spring's relaxed binding
(see CAMEL-24503).
The mapping has a second defect that shows once the filter works: the known
name of a variable is the first entry of a {{HashSet}} that is a plain prefix
of it ({{componentEnvNames.stream().filter(k::startsWith).findFirst()}}). 31
component names are followed by {{_}} and another name ({{NETTY}} /
{{NETTY_HTTP}}, {{REST}} / {{REST_OPENAPI}}, {{SQL}} / {{SQL_STORED}}, {{FILE}}
/ {{FILE_WATCH}}, {{VERTX}} / {{VERTX_HTTP}}, ...) and 18 component, 3 data
format and 2 language names are plain prefixes of another one ({{HTTP}} /
{{HTTPS}}, {{FTP}} / {{FTPS}}, {{SJMS}} / {{SJMS2}}, {{ACTIVEMQ}} /
{{ACTIVEMQ6}}, {{AVRO}} / {{AVROJACKSON}}, {{JS}} / {{JSONPATH}}, ...). With
the current set order, {{CAMEL_COMPONENT_NETTY_HTTP_MUTE_EXCEPTION}} becomes
{{camel.component.netty.http-mute-exception}},
{{CAMEL_COMPONENT_SJMS2_RECOVERY_INTERVAL}} becomes
{{camel.component.sjms.-recovery-interval}},
{{CAMEL_LANGUAGE_JSONPATH_SUPPRESS_EXCEPTIONS}} becomes
{{camel.language.js.npath-suppress-exceptions}}, and the same for
{{sql-stored}}, {{ftps}}, {{file-watch}}, {{activemq6}} and {{avroJackson}}
(which then fail the startup with fail-fast, or configure the wrong component).
h3. Reproduction
New {{MainComponentEnvVariablesTest}} (sets the variables in the JVM like
{{MainPropertyPlaceholderWithEnvTest}}): with
{{CAMEL_COMPONENT_SEDA_QUEUE_SIZE=123}} the seda component has {{queueSize}}
500 (from {{application.properties}}) instead of 123; the control with
{{autoConfigurationEnvironmentVariablesEnabled=false}} passes. Two new
{{MainHelperTest}} tests: 8 of the 15 variables above are mapped to the shorter
name. Two runs on main.
h3. Proposed fix
Filter with {{CAMEL_COMPONENT_}}, {{CAMEL_DATAFORMAT_}} and
{{CAMEL_LANGUAGE_}}, and take the longest known name that the variable starts
with followed by {{_}} (one helper for the three kinds). Behaviour change,
upgrade guide entry: such variables now configure Camel, so a stray variable
for a component that is not on the classpath, or for an unknown option, fails
the startup like the same property in a file (unless
{{autoConfigurationFailFast=false}}). The Kubernetes service variables skipped
for {{camel.main.*}} (CAMEL-19701) are not skipped here, since component
options can end with {{_PORT}}; a service named {{camel-component-...}} would
be needed to collide. camel-main: 287 tests pass.
Found with a Lean 4 model of {{filterEnvVariables}} and of the name lookup: "a
variable CAMEL_COMPONENT_<name>_<option> configures <name>.<option>" fails on
main for every variable (the upper-cased name never starts with {{c}}) and, for
the name lookup, whenever the shorter name comes first in the set (for every
pair of names); the fix is proved to pick the longest name followed by {{_}},
independently of the set order, and the same name as main whenever only one
name is a prefix of the variable.
Affected: 3.9 to main (4.14.x and 4.18.x have the same code). Since the fix
makes variables that are ignored today take effect (and can fail the startup),
it is meant for 4.23 with the upgrade note, not for the 4.14.x / 4.18.x
maintenance branches.
Duplicate check (2026-10-05): JIRA summaries with "env"/"environment variable"
and component, camel-main issues since 2026-09; GitHub pull requests
"filterEnvVariables", "CAMEL_COMPONENT environment", open PRs on MainHelper /
BaseMainSupport: none.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
