[
https://issues.apache.org/jira/browse/CAMEL-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24913:
--------------------------------
Description:
h2. Background
CAMEL-24871 added {{camel-jev}} (merged to main as ee626c6e9307, Camel 4.23.0).
Besides the component, it ships a {{jev}} language that is exposed through the
generic {{LanguageExpression}} model rather than a dedicated model in
camel-core, using the new {{@Language(modelName = "language")}} attribute.
h2. Problem
Spring Boot starters are source-generated in {{apache/camel-spring-boot}}, and
the generated {{*LanguageConfiguration}} class is derived from the language's
JSON model. Because {{jev}} reuses the generic model, its language JSON only
carries the generic {{LanguageExpression}} properties:
{{id}}, {{language}}, {{expression}}, {{trim}}, {{resolveResource}}
None of the options that actually configure a Jev evaluation are there. Those
live on the component/endpoint:
{{apiKey}}, {{model}}, {{questions}}, {{state}}, {{threshold}},
{{uncertainty}}, {{uncertaintyPolicy}}, {{baseUrl}}, {{requestTimeout}},
{{maxConcurrentRequests}}
So a purely generated {{camel-jev-starter}} would produce a
{{JevLanguageConfiguration}} under {{camel.language.jev.*}} that exposes
nothing useful — there is no way to set the API key or the question through it.
Code generation cannot close this gap, because the generator has no
jev-specific model to read from.
h2. Proposal
Hand-craft {{camel-jev-starter}} rather than relying on the generated output,
the way {{camel-platform-http-starter}} is maintained today. That starter
carries eight hand-written classes in {{src/main/java}}, including its own
{{PlatformHttpComponentConfiguration}} and
{{PlatformHttpComponentAutoConfiguration}}, plus a full test suite. Around 25
starters already carry hand-written code, so this is an established pattern
rather than a new exception — for example {{camel-jetty-starter}},
{{camel-jasypt-starter}}, {{camel-core-starter}}, {{camel-mcp-server-starter}}.
Scope to work out:
* Write {{JevLanguageConfiguration}} / {{JevLanguageAutoConfiguration}} by hand
so the jev options are settable from Spring Boot properties, and decide the
namespace — hand-written {{camel.language.jev.*}} covering the jev options, or
document {{camel.component.jev.*}} as the single source of configuration with
the language resolving against it.
* Determine how the starter is kept out of regeneration so the hand-written
classes are not clobbered on the next sync. The exact opt-out mechanism used by
{{camel-platform-http-starter}} still needs to be identified — it is not simply
a flag in that module's pom.
* Add Spring Boot tests covering a route that uses the {{jev}} language
configured purely from {{application.properties}}.
* Document the resulting property set in the component docs.
h2. Related
CAMEL-24914 tracks the generator-side question: {{jev}} is the first language
to use {{@Language(modelName = "language")}}, so the starter generator has
never seen a language backed by the generic model. That matters for future
components regardless of how {{camel-jev-starter}} itself is built.
_Claude Code on behalf of davsclaus_
was:
h2. Background
CAMEL-24871 added {{camel-jev}} (merged to main as ee626c6e9307, Camel 4.23.0).
Besides the component, it ships a {{jev}} language that is exposed through the
generic {{LanguageExpression}} model rather than a dedicated model in
camel-core, using the new {{@Language(modelName = "language")}} attribute.
h2. Problem
Spring Boot starters are source-generated in {{apache/camel-spring-boot}}, and
the generated {{*LanguageConfiguration}} class is derived from the language's
JSON model. Because {{jev}} reuses the generic model, its language JSON only
carries the generic {{LanguageExpression}} properties:
{{id}}, {{language}}, {{expression}}, {{trim}}, {{resolveResource}}
None of the options that actually configure a Jev evaluation are there. Those
live on the component/endpoint:
{{apiKey}}, {{model}}, {{questions}}, {{state}}, {{threshold}},
{{uncertainty}}, {{uncertaintyPolicy}}, {{baseUrl}}, {{requestTimeout}},
{{maxConcurrentRequests}}
So the generated {{camel-jev-starter}} would produce a
{{JevLanguageConfiguration}} under {{camel.language.jev.*}} that exposes
nothing useful — there is no way to set the API key or the question through it.
Code generation cannot close this gap, because the generator has no
jev-specific model to read from.
h2. Proposal
Hand-code the language configuration in {{camel-jev-starter}} so the {{jev}}
language is configurable from Spring Boot properties, rather than relying on
the generated class.
Scope to work out:
* Decide the property namespace — hand-written {{camel.language.jev.*}}
covering the jev options, or document {{camel.component.jev.*}} as the single
source of configuration and make the language resolve against it.
* Ensure the hand-written configuration is not clobbered on the next starter
regeneration (exclusion list / {{@Generated}} handling in the starter tooling).
* Verify the generated {{JevLanguageAutoConfiguration}} does not conflict with,
or silently override, the hand-coded one.
* Add a Spring Boot test covering a route that uses the {{jev}} language
configured purely from {{application.properties}}.
* Document the resulting property set in the component docs.
h2. Note
This is the first language to use {{@Language(modelName = "language")}}, so the
starter tooling in camel-spring-boot has not seen this shape before. Worth
checking whether the generator handles it cleanly at all, or whether it needs a
guard for languages backed by the generic model — that part may deserve a
follow-up issue of its own.
_Claude Code on behalf of davsclaus_
Summary: camel-jev-starter: hand-craft the Spring Boot starter so the
jev language can be configured (was: camel-jev-starter: hand-code the Spring
Boot configuration for the jev language)
> camel-jev-starter: hand-craft the Spring Boot starter so the jev language can
> be configured
> -------------------------------------------------------------------------------------------
>
> Key: CAMEL-24913
> URL: https://issues.apache.org/jira/browse/CAMEL-24913
> Project: Camel
> Issue Type: New Feature
> Components: camel-ai, camel-spring-boot-starters
> Reporter: Claus Ibsen
> Priority: Major
>
> h2. Background
> CAMEL-24871 added {{camel-jev}} (merged to main as ee626c6e9307, Camel
> 4.23.0). Besides the component, it ships a {{jev}} language that is exposed
> through the generic {{LanguageExpression}} model rather than a dedicated
> model in camel-core, using the new {{@Language(modelName = "language")}}
> attribute.
> h2. Problem
> Spring Boot starters are source-generated in {{apache/camel-spring-boot}},
> and the generated {{*LanguageConfiguration}} class is derived from the
> language's JSON model. Because {{jev}} reuses the generic model, its language
> JSON only carries the generic {{LanguageExpression}} properties:
> {{id}}, {{language}}, {{expression}}, {{trim}}, {{resolveResource}}
> None of the options that actually configure a Jev evaluation are there. Those
> live on the component/endpoint:
> {{apiKey}}, {{model}}, {{questions}}, {{state}}, {{threshold}},
> {{uncertainty}}, {{uncertaintyPolicy}}, {{baseUrl}}, {{requestTimeout}},
> {{maxConcurrentRequests}}
> So a purely generated {{camel-jev-starter}} would produce a
> {{JevLanguageConfiguration}} under {{camel.language.jev.*}} that exposes
> nothing useful — there is no way to set the API key or the question through
> it. Code generation cannot close this gap, because the generator has no
> jev-specific model to read from.
> h2. Proposal
> Hand-craft {{camel-jev-starter}} rather than relying on the generated output,
> the way {{camel-platform-http-starter}} is maintained today. That starter
> carries eight hand-written classes in {{src/main/java}}, including its own
> {{PlatformHttpComponentConfiguration}} and
> {{PlatformHttpComponentAutoConfiguration}}, plus a full test suite. Around 25
> starters already carry hand-written code, so this is an established pattern
> rather than a new exception — for example {{camel-jetty-starter}},
> {{camel-jasypt-starter}}, {{camel-core-starter}},
> {{camel-mcp-server-starter}}.
> Scope to work out:
> * Write {{JevLanguageConfiguration}} / {{JevLanguageAutoConfiguration}} by
> hand so the jev options are settable from Spring Boot properties, and decide
> the namespace — hand-written {{camel.language.jev.*}} covering the jev
> options, or document {{camel.component.jev.*}} as the single source of
> configuration with the language resolving against it.
> * Determine how the starter is kept out of regeneration so the hand-written
> classes are not clobbered on the next sync. The exact opt-out mechanism used
> by {{camel-platform-http-starter}} still needs to be identified — it is not
> simply a flag in that module's pom.
> * Add Spring Boot tests covering a route that uses the {{jev}} language
> configured purely from {{application.properties}}.
> * Document the resulting property set in the component docs.
> h2. Related
> CAMEL-24914 tracks the generator-side question: {{jev}} is the first language
> to use {{@Language(modelName = "language")}}, so the starter generator has
> never seen a language backed by the generic model. That matters for future
> components regardless of how {{camel-jev-starter}} itself is built.
> _Claude Code on behalf of davsclaus_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
