[jira] [Resolved] (CAMEL-24661) camel-jbang: feature parity for camel run CLI flags across the Camel Main, Spring Boot and Quarkus runtimes (--console, max duration, log file)

["Claus Ibsen (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CAMEL-24661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Claus Ibsen resolved CAMEL-24661.
---------------------------------
    Resolution: Fixed

> camel-jbang: feature parity for camel run CLI flags across the Camel Main, Spring Boot and Quarkus runtimes (--console, max duration, log file)
> -----------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-24661
>                 URL: https://issues.apache.org/jira/browse/CAMEL-24661
>             Project: Camel
>          Issue Type: Improvement
>          Components: camel-jbang
>            Reporter: Claus Ibsen
>            Assignee: Claus Ibsen
>            Priority: Major
>             Fix For: 4.23.0
>
>
> Follow-up to CAMEL-24659, which made {{camel run --runtime=main}} export and run in a separate JVM like Spring Boot and Quarkus, and added {{--console}} support for the exported Camel Main project. While doing that, a gap analysis of which {{camel run}} flags survive the export on each runtime was made. Most flags already have parity; the gaps are the developer console, the max duration options and the Quarkus log file name.
> h3. Where each camel run flag lands today
> ||Flag||Camel Main (after CAMEL-24659)||Spring Boot||Quarkus||
> |{{--port}}, {{--management-port}}|yes|yes ({{server.port}}, {{management.server.port}})|yes ({{quarkus.http.port}}, {{quarkus.management.port}})|
> |{{--observe}}|yes|yes, via {{camel-observability-services-starter}}|yes, via the extension|
> |{{--console}}|yes|no|no|
> |{{--dev}}|reload from source dir|devtools|{{quarkus:dev}}|
> |{{--jvm-args}}, {{--jfr}}, {{--jvm-debug}}|yes|jvm args and JFR yes|jvm args and JFR yes|
> |{{--max-seconds}}, {{--max-messages}}, {{--max-idle-seconds}}|yes|ignored|ignored|
> |log file named after {{camel.main.name}}|yes|pid based (fine)|named after the export name (mismatch)|
> h3. What --console needs on each runtime
> *Spring Boot*: the console is an actuator endpoint with id {{camel}} ({{CamelDevConsoleEndpoint}}), gated by {{camel.main.devConsoleEnabled}} (the exporter only renames {{camel.main.*}} to {{camel.springboot.*}} for 4.4 and older, so the key works). It needs the {{camel-console-starter}} dependency and {{camel}} added to {{management.endpoints.web.exposure.include}}. The actuator starter is already in the exported pom template, and {{ExportSpringBoot}} already does exactly this for hawtio/jolokia, so it is a copy of that block. Default path is {{/actuator/camel}}. Jolokia parity is {{camel-jolokia-starter}} plus {{jolokia}} in the exposure list.
> *Quarkus*: the console is the {{camel-quarkus-console}} extension with {{quarkus.camel.console.enabled=true}} (or {{camel.main.dev-console-enabled=true}}). Default path is {{/q/camel/dev-console}}. Catch: it is only exposed in dev and test mode by default, and {{camel run --runtime=quarkus}} without {{--dev}} uses {{quarkus:run}} which is prod mode, so the export must also set {{quarkus.camel.console.exposure-mode=all}} (documented by Quarkus as unauthenticated). Health is {{/q/health}} via {{camel-quarkus-microprofile-health}} and Jolokia is {{/q/jolokia}} via {{camel-quarkus-jolokia}}.
> h3. Parity opportunity: the URL
> Tooling such as Kaoto hardcodes {{/q/dev}}. Both runtimes can be put on that path: Quarkus via {{quarkus.camel.console.path=dev}} (non-application endpoints live under {{/q/}}), and Spring Boot via {{management.endpoints.web.base-path=/q}} plus {{management.endpoints.web.path-mapping.camel=dev}}. That lets external tools work unchanged across all three runtimes.
> Trade-off: the observability-services starter injects {{/observe}} as the actuator base path and {{health,prometheus}} as the exposure list, at lowest precedence. Setting the exposure list for the console overrides those defaults, so the export must merge them ({{health,prometheus,camel}}) when {{--observe}} and {{--console}} are combined, and a base path of {{/q}} moves the probes away from {{/observe/*}} unless mapped individually. Camel Main already serves {{/q/dev}} and {{/observe/*}} side by side and is the reference behaviour.
> h3. Max duration options
> camel-spring-boot and camel-quarkus both honour {{camel.main.durationMaxSeconds}}, {{durationMaxMessages}} and {{durationMaxIdleSeconds}}, so they can be passed as system properties in the existing {{spring-boot.run.jvmArguments}} and {{jvm.args}} arguments, the same way the Camel Main run does after CAMEL-24659.
> h3. Proposal
> # {{--console}} for Spring Boot and Quarkus, implemented in {{ExportSpringBoot}} / {{ExportQuarkus}} from the {{camel.jbang.console}} run setting (like {{ExportCamelMain}}), mapped onto {{/q/dev}}, with the exposure list merge for {{--observe}} and the Quarkus exposure-mode note in the docs. Cover with {{ExportTest}} cases per runtime.
> # Forward the max duration options to the Spring Boot and Quarkus child JVMs.
> # Name the Quarkus run log file after {{camel.main.name}} like Camel Main does (likely why the TUI Log tab is empty for Quarkus apps).
> Risk is low; the only judgement call is exposing the Quarkus console in prod mode for a local run, which is acceptable for {{camel run}} as a developer tool, but the exported project should carry a comment saying so.
> ----
> _Created by Claude Code on behalf of davsclaus_



--
This message was sent by Atlassian Jira
(v8.20.10#820010)