shashank created CAMEL-26769:
--------------------------------
Summary: camel-sanitizer - dev console, camel get sanitizer and
camel run --sanitizer
Key: CAMEL-26769
URL: https://issues.apache.org/jira/browse/CAMEL-26769
Project: Camel
Issue Type: Improvement
Components: camel-jbang, camel-core
Reporter: shashank
Assignee: shashank
Step 5 of the order of work in the exchange sanitizer design
({{design/exchange-sanitizer.adoc}}, CAMEL-26630): the report of
{{camel-sanitizer}} (CAMEL-26714) in a running integration, as the design
describes it under "Using it": a {{sanitizer}} developer console, {{camel get
sanitizer}} and {{camel run --sanitizer}}. Today the violations are only in the
log and, from Java, in {{Sanitizer.get(camelContext)}}.
*What it adds*
* A {{sanitizer}} developer console in {{camel-sanitizer}} (read-only, no
options). In JSON: {{enabled}} (and the {{reason}} when it is off: profile
{{prod}}, or not switched on), {{calls}} (the calls of steps checked),
{{total}}, the counts per rule ({{rules}}, such as {{R1}}) and per kind
({{kinds}}), and the violations (the first 1000, as the sanitizer keeps them)
with their rule, kind, route, step, processor, exchange id and full report
(threads, stacks, and the class and message of what was thrown). As text it is
the report that is logged when the context stops. The report holds ids, names,
threads, stacks and exception class and message, never bodies or headers. An
exception message can still carry message data, so the console is for
development; like every developer console it is served over HTTP only when the
developer consoles are switched on (with Camel Main,
{{camel.management.devConsoleEnabled=true}}, an {{insecure:dev}} option).
* {{Violation.getRule()}} ({{R1}} for the kinds of this version), for the
counts per rule.
* {{camel get sanitizer}}: a table of the violations of the running
integrations (rule, kind, route, step, processor, exchange), and with
{{--report}} the counts per rule and kind and each violation with its stacks;
{{--json}} for both. It says why an integration has nothing to show (the
sanitizer is off, no violations, the integration did not answer in time, no
{{camel-sanitizer}}: run it with {{camel run --sanitizer}}), and how many
violations are counted past the first 1000 but not listed. An integration whose
status says Camel before 4.24 is not asked. It asks the integration for the
console through a {{sanitizer}} action of the CLI connector when it runs, as
{{camel get timeline}} does, rather than reading it from the status file the
connector writes each second (as {{camel get chaos}} does): the report can list
1000 violations with their stacks.
* {{camel run --sanitizer}} (also {{dev}} and {{debug}}) adds
{{camel-sanitizer}}, as {{--chaos}} adds {{camel-chaos}}; {{--dep
camel:sanitizer}} keeps working. With profile {{dev}}, the default of {{camel
run}}, it is on; with profile {{prod}} the run says up front that it stays off.
With {{--runtime=main}} and an existing Camel Main project the dependency is
added to the exported or run project. With {{--runtime=spring-boot}} it is
plain {{camel-sanitizer}} (there is no starter; for an existing project with
the version the Camel Spring Boot BOM is imported with) and the run passes
{{-Dcamel.sanitizer.enabled=true}} unless the profile is {{prod}}, as
CAMEL-26479 settled for {{--chaos}}. With {{--runtime=quarkus}} it is refused
for now with a usage error: there is no Camel Quarkus extension to add to an
existing Quarkus project ({{--chaos}} uses {{camel-quarkus-chaos}} there), and
the sanitizer is not tested with Camel Quarkus yet; a follow-up can lift that
as CAMEL-26479 did for chaos.
*Not in this step*
* The calls still pending (R1 "still pending", CAMEL-26751): the console shows
what {{camel-sanitizer}} keeps on main; the pending calls are added to it with
that change.
* {{camel run --sanitizer}} with Camel Quarkus.
*Tests*
* camel-core: the console as JSON and as text for a context with a violation
(the counts, the report with the stack and the exception, and no body or
header), with no violation, off with profile {{prod}}, and found by its id as
read-only.
* camel-cli-connector: the {{sanitizer}} action end to end, on with a violation
and off with profile {{prod}}.
* camel-jbang-core: {{camel get sanitizer}} as a table, as JSON, the report,
the notes (off, no violations, not listed, did not answer, no camel-sanitizer,
before 4.24), the real request against a fake integration; {{camel run
--sanitizer}} in the run and export golden files (JBang and Spring Boot), the
WARN with profile {{prod}}, the refusal with Quarkus; camel-jbang-run: Spring
Boot (exported and existing project, profile {{prod}}) and an existing Camel
Main project.
_Filed with Claude Code on behalf of allthingssecurity._
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
