[
https://issues.apache.org/jira/browse/CAMEL-25352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18123628#comment-18123628
]
Guillaume Nodet commented on CAMEL-25352:
-----------------------------------------
This issue is being investigated by a coding agent (on behalf of gnodet).
Two bugs confirmed in MainHelper.java on main branch:
*Bug 1*: filterEnvVariables is called with lowercase dotted prefixes
("camel.component.", "camel.dataformat.", "camel.language.") but the filter
logic uppercases env var names before comparing, so the filter never matches
and all CAMEL_COMPONENT_*, CAMEL_DATAFORMAT_*, CAMEL_LANGUAGE_* env vars are
silently ignored.
*Bug 2*: When looking up component names from env vars, the code uses
stream().filter(k::startsWith).findFirst() on a HashSet with no guaranteed
iteration order. For overlapping names like CAMEL_COMPONENT_NETTY vs
CAMEL_COMPONENT_NETTY_HTTP, whichever comes first in the HashSet wins, causing
nondeterministic mapping to the wrong component.
A fix is being prepared targeting MainHelper.java: correcting the filter
prefixes to uppercase/underscore form and using longest-match instead of
findFirst.
_Note: This comment was generated by an AI coding agent and requires manual
verification._
> 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
> Assignee: Guillaume Nodet
> Priority: Major
>
> {{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)
