[
https://issues.apache.org/jira/browse/CAMEL-23644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-23644:
--------------------------------
Description:
Currently the camel-cli-connector-starter has matchIfMissing = true in its
@ConditionalOnProperty annotation, meaning the CLI connector is enabled by
default for all Spring Boot Camel applications, including production
deployments.
The CLI connector is a development-time tool that enables the Camel JBang CLI
(camel top, camel trace, camel tui, camel ai etc.) to discover and interact
with running Camel applications. It should not be active in production by
default.
h3. Problem
There is no reliable way to auto-detect dev vs production mode in Spring Boot:
- Fat JARs use LaunchedURLClassLoader (detectable)
- Layered JARs extracted in Docker use regular classloaders (indistinguishable
from dev mode)
- Thin JARs use regular classloaders (indistinguishable from dev mode)
- Spring Boot DevTools has the same limitation
- Spring profiles are common (dev/prod) but there is no standard profile name
h3. Proposed changes
1. *Change default to opt-in:* Change @ConditionalOnProperty(name =
"camel.cli.enabled", matchIfMissing = true) to matchIfMissing = false in
CliConnectorAutoConfiguration.java
2. *Consider optional runtime scope:* Some users may feel the
cli-connector-starter dependency is invasive if included transitively. Consider
making it optional and runtime scoped so it does not leak into downstream
projects.
3. *Automatic enablement via mvn spring-boot:run:* Investigate whether the
Spring Boot Maven plugin (and Gradle bootRun) can automatically set
camel.cli.enabled=true when running in dev mode. The spring-boot-maven-plugin
forks a new JVM process — it could pass -Dcamel.cli.enabled=true as a JVM
argument automatically, or the auto-configuration could detect the forked
process classloader. This would give developers zero-config enablement during
development without any risk of production activation.
4. *Camel dev profile integration:* When the CLI connector is enabled (dev
mode), also set camel.main.profile=dev to activate the Camel dev profile. This
provides extra insights for users and better integration with the Camel CLI and
TUI — such as enhanced logging, dev consoles, and runtime diagnostics that are
useful during development but should not be active in production.
5. *Document recommended setup:* Users opt-in via camel.cli.enabled=true in
their dev profile (application-dev.properties) or via command line
-Dcamel.cli.enabled=true. Document the automatic enablement when using mvn
spring-boot:run.
h3. Recommended user setup (manual)
{code}
# application-dev.properties
camel.cli.enabled=true
{code}
or:
{code}
mvn spring-boot:run -Dcamel.cli.enabled=true
{code}
h3. Ideal user experience (automatic)
When running via mvn spring-boot:run or gradle bootRun, the CLI connector and
Camel dev profile are enabled automatically — no configuration needed. When
running as a packaged JAR in production, both are disabled. The developer gets
full TUI, trace, and AI support during development with zero setup.
This ensures zero overhead in production regardless of JAR packaging type,
while making it trivially easy for developers to get the full Camel development
experience.
was:
Currently the camel-cli-connector-starter has matchIfMissing = true in its
@ConditionalOnProperty annotation, meaning the CLI connector is enabled by
default for all Spring Boot Camel applications, including production
deployments.
The CLI connector is a development-time tool that enables the Camel JBang CLI
(camel top, camel trace, camel tui, camel ai etc.) to discover and interact
with running Camel applications. It should not be active in production by
default.
h3. Problem
There is no reliable way to auto-detect dev vs production mode in Spring Boot:
- Fat JARs use LaunchedURLClassLoader (detectable)
- Layered JARs extracted in Docker use regular classloaders (indistinguishable
from dev mode)
- Thin JARs use regular classloaders (indistinguishable from dev mode)
- Spring Boot DevTools has the same limitation
- Spring profiles are common (dev/prod) but there is no standard profile name
h3. Proposed changes
1. *Change default to opt-in:* Change @ConditionalOnProperty(name =
"camel.cli.enabled", matchIfMissing = true) to matchIfMissing = false in
CliConnectorAutoConfiguration.java
2. *Consider optional runtime scope:* Some users may feel the
cli-connector-starter dependency is invasive if included transitively. Consider
making it optional and runtime scoped so it does not leak into downstream
projects.
3. *Document recommended setup:* Users opt-in via camel.cli.enabled=true in
their dev profile (application-dev.properties) or via command line
-Dcamel.cli.enabled=true
h3. Recommended user setup
{code}
# application-dev.properties
camel.cli.enabled=true
{code}
or:
{code}
mvn spring-boot:run -Dcamel.cli.enabled=true
{code}
This ensures zero overhead in production regardless of JAR packaging type,
while making it trivially easy for developers to enable during development.
> camel-cli-connector-starter - Make opt-in and consider optional runtime scope
> -----------------------------------------------------------------------------
>
> Key: CAMEL-23644
> URL: https://issues.apache.org/jira/browse/CAMEL-23644
> Project: Camel
> Issue Type: Improvement
> Components: camel-spring-boot
> Reporter: Claus Ibsen
> Priority: Major
>
> Currently the camel-cli-connector-starter has matchIfMissing = true in its
> @ConditionalOnProperty annotation, meaning the CLI connector is enabled by
> default for all Spring Boot Camel applications, including production
> deployments.
> The CLI connector is a development-time tool that enables the Camel JBang CLI
> (camel top, camel trace, camel tui, camel ai etc.) to discover and interact
> with running Camel applications. It should not be active in production by
> default.
> h3. Problem
> There is no reliable way to auto-detect dev vs production mode in Spring Boot:
> - Fat JARs use LaunchedURLClassLoader (detectable)
> - Layered JARs extracted in Docker use regular classloaders
> (indistinguishable from dev mode)
> - Thin JARs use regular classloaders (indistinguishable from dev mode)
> - Spring Boot DevTools has the same limitation
> - Spring profiles are common (dev/prod) but there is no standard profile name
> h3. Proposed changes
> 1. *Change default to opt-in:* Change @ConditionalOnProperty(name =
> "camel.cli.enabled", matchIfMissing = true) to matchIfMissing = false in
> CliConnectorAutoConfiguration.java
> 2. *Consider optional runtime scope:* Some users may feel the
> cli-connector-starter dependency is invasive if included transitively.
> Consider making it optional and runtime scoped so it does not leak into
> downstream projects.
> 3. *Automatic enablement via mvn spring-boot:run:* Investigate whether the
> Spring Boot Maven plugin (and Gradle bootRun) can automatically set
> camel.cli.enabled=true when running in dev mode. The spring-boot-maven-plugin
> forks a new JVM process — it could pass -Dcamel.cli.enabled=true as a JVM
> argument automatically, or the auto-configuration could detect the forked
> process classloader. This would give developers zero-config enablement during
> development without any risk of production activation.
> 4. *Camel dev profile integration:* When the CLI connector is enabled (dev
> mode), also set camel.main.profile=dev to activate the Camel dev profile.
> This provides extra insights for users and better integration with the Camel
> CLI and TUI — such as enhanced logging, dev consoles, and runtime diagnostics
> that are useful during development but should not be active in production.
> 5. *Document recommended setup:* Users opt-in via camel.cli.enabled=true in
> their dev profile (application-dev.properties) or via command line
> -Dcamel.cli.enabled=true. Document the automatic enablement when using mvn
> spring-boot:run.
> h3. Recommended user setup (manual)
> {code}
> # application-dev.properties
> camel.cli.enabled=true
> {code}
> or:
> {code}
> mvn spring-boot:run -Dcamel.cli.enabled=true
> {code}
> h3. Ideal user experience (automatic)
> When running via mvn spring-boot:run or gradle bootRun, the CLI connector and
> Camel dev profile are enabled automatically — no configuration needed. When
> running as a packaged JAR in production, both are disabled. The developer
> gets full TUI, trace, and AI support during development with zero setup.
> This ensures zero overhead in production regardless of JAR packaging type,
> while making it trivially easy for developers to get the full Camel
> development experience.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
