Serdar Gökay created CAMEL-25384:
------------------------------------
Summary: camel-kubernetes - the kubernetes-secrets dev console
throws NPE when no Kubernetes vault is configured, so camel ps/get do not show
the integration
Key: CAMEL-25384
URL: https://issues.apache.org/jira/browse/CAMEL-25384
Project: Camel
Issue Type: Bug
Components: camel-kubernetes, camel-jbang
Affects Versions: 4.22.1
Environment: Camel JBang 4.22.1, JBang 0.142.0, Java 25.0.4, macOS;
also seen in a Linux container on Kubernetes
Reporter: Serdar Gökay
When camel-kubernetes is on the classpath and
{{camel.vault.kubernetes.secrets}} is not set, the JSON output of the
{{kubernetes-secrets}} dev console throws a NullPointerException.
{{LocalCliConnector}} calls this console through {{collectVaults()}} on every
status update, so the status file {{~/.camel/<pid>-status.json}} is never
written. The integration runs normally, but {{camel ps}}, {{camel get}} and
{{camel get route}} do not list it, and the MCP tools that read the status
({{get_routes}}, {{get_context}}) answer "No status available for PID ...". The
exception is logged at TRACE only.
h3. Reproduce
Camel JBang 4.22.1, no Kubernetes cluster needed. {{demo.camel.yaml}}:
{noformat}
- route:
id: tick
from:
uri: timer:tick
steps:
- log: tick
- route:
id: echo
from:
uri: direct:echo
steps:
- log: "foo=${header.foo}"
{noformat}
{noformat}
camel run demo.camel.yaml --dep=camel-kubernetes
camel ps # the integration is not listed, and ~/.camel/<pid>-status.json
stays empty
{noformat}
Without {{--dep=camel-kubernetes}}, or with
{{--prop=camel.vault.kubernetes.secrets=x}}, the integration is listed.
With {{--logging-category=org.apache.camel.cli.connector=TRACE}}:
{noformat}
TRACE LocalCliConnector : Error updating status file: ~/.camel/7203-status.json
due to: Cannot invoke "String.split(String)" because the return value of
"org.apache.camel.vault.KubernetesVaultConfiguration.getSecrets()" is null.
This exception is ignored.
java.lang.NullPointerException: Cannot invoke "String.split(String)" because
the return value of
"org.apache.camel.vault.KubernetesVaultConfiguration.getSecrets()" is null
at
org.apache.camel.component.kubernetes.secrets.vault.SecretsDevConsole.doCallJson(SecretsDevConsole.java:125)
...
at
org.apache.camel.cli.connector.LocalCliConnector.collectVaults(LocalCliConnector.java:2009)
at
org.apache.camel.cli.connector.LocalCliConnector.statusTask(LocalCliConnector.java:1765)
{noformat}
h3. Cause
{{SecretsDevConsole}} splits {{getSecrets()}} without a null check:
unconditionally in {{doCallJson}}, and in {{doCallText}} after checking only
that the configuration object exists. On main, {{getSecrets()}} is declared
{{@Nullable}}, and the line in {{doCallJson}} carries the note "kubernetes is
dereferenced unconditionally here, same as the original code - preserved as-is
rather than fixed" (from CAMEL-24565). The AWS, GCP, Azure and HashiCorp vault
consoles check their configuration for null before using it.
{{ConfigmapsDevConsole}} has the same split. Its text and JSON output also read
the Secrets vault configuration
({{getKubernetesVaultConfiguration().getSecrets()}}) instead of
{{getKubernetesConfigMapVaultConfiguration().getConfigmaps()}}. With only
{{camel.vault.kubernetes.secrets=none}} set, the status file lists {{none}}
under {{kubernetes-configmaps}}.
The same code is in 4.18.x and on main. A null check as in the other vault
consoles, and reading the ConfigMap vault configuration in
{{ConfigmapsDevConsole}}, would fix both.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
