Claus Ibsen created CAMEL-24913:
-----------------------------------
Summary: camel-jev-starter: hand-code the Spring Boot
configuration for the jev language
Key: CAMEL-24913
URL: https://issues.apache.org/jira/browse/CAMEL-24913
Project: Camel
Issue Type: New Feature
Components: camel-spring-boot-starters, camel-ai
Reporter: Claus Ibsen
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_
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
