[
https://issues.apache.org/jira/browse/CAMEL-24913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Claus Ibsen updated CAMEL-24913:
--------------------------------
Fix Version/s: 4.23.0
> 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
> Fix For: 4.23.0
>
>
> 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)
