[
https://issues.apache.org/jira/browse/CAMEL-26769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on CAMEL-26769 started by shashank.
----------------------------------------
> 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-core, camel-jbang
> Reporter: shashank
> Assignee: shashank
> Priority: Major
>
> 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)
