luigidemasi opened a new issue, #102: URL: https://github.com/apache/camel-kit/issues/102
> Imported from [luigidemasi/camel-kit#238](https://github.com/luigidemasi/camel-kit/issues/238), opened by [luigidemasi](https://github.com/luigidemasi) on 2026-09-18. > Closed by [luigidemasi/camel-kit#239](https://github.com/luigidemasi/camel-kit/pull/239), merged on 2026-09-18. --- ## Description Make declarative bean construction the default in the shared generation and review guidance whenever the configured Camel runtime and dependency versions support it. Prefer YAML constructors/properties, factory methods or factory beans, and supported builders over `scriptLanguage` for bean initialization. Keep scripts available when the required initialization cannot be expressed with those mechanisms. This should be a Camel Kit default shared by all supported agents, rather than a per-project prompt workaround. ## Observed behavior A Camel Main 4.22.0 integration for MQTT weather telemetry and InfluxDB 2 generated this bean: ```yaml - beans: - name: influxDbClient type: com.influxdb.client.InfluxDBClient scriptLanguage: groovy script: | import com.influxdb.client.InfluxDBClientFactory return InfluxDBClientFactory.create( '{{influxdb.url}}', '{{influxdb.token}}'.toCharArray(), '{{influxdb.org}}', '{{influxdb.bucket}}' ) ``` The generated comment claimed scripting was necessary because the factory class had no no-argument constructor. That is incorrect for a supported public static factory method. The following declaration was verified in an isolated Camel Main 4.22.0 process with InfluxDB Java client 7.5.0 and dummy configuration: ```yaml - beans: - name: influxDbClient type: com.influxdb.client.InfluxDBClient factoryBean: com.influxdb.client.InfluxDBClientFactory factoryMethod: create constructors: 0: "{{influxdb.url}}" 1: "{{influxdb.token}}" 2: "{{influxdb.org}}" 3: "{{influxdb.bucket}}" destroyMethod: close ``` Camel registered `InfluxDBClientImpl`, converted the token from `String` to `char[]`, and completed shutdown with `destroyMethod: close`. This verifies bean creation and shutdown, not database connectivity or end-to-end telemetry ingestion. ## Expected behavior Preserve the existing infrastructure configuration order: 1. Use Forage when its verified catalog covers the requirement. 2. Otherwise use verified component scalar configuration when sufficient. 3. When a custom bean is necessary, prefer the simplest supported declarative construction: constructors/properties, `factoryMethod`/`factoryBean`, or a supported builder. 4. Use `scriptLanguage` only when declarative construction cannot express the required initialization, and record the concrete reason. Before choosing a declaration, verify the relevant YAML DSL support, library API, method signature, argument conversions, and lifecycle requirements for the actual runtime and dependency versions. Do not invent factory methods, assume builder support, or treat a failed documentation lookup as proof that no declarative alternative exists. A missing no-argument constructor alone does not justify scripting when a suitable static factory exists. This preference concerns bean initialization. It does not ban scripts used for message transformations or change the existing DataMapper engine-selection rules. ## Suggested implementation scope At inspected main `c9d99c0a247a2b15d336b72700beedb5615ba13d`, the shared infrastructure ladder describes the custom-bean fallback, but the YAML generation guide has no factory-versus-script selection rule. Align: - `camel-kit-core/src/main/resources/skills/shared/forage.md` - `camel-kit-core/src/main/resources/skills/camel-implement/guides/yaml-structure.md` and related property-generation guidance - The shared implementation self-validation and code-quality review criteria/persona Use one shared policy, referenced by the relevant workflow stages, to keep all generated agent distributions consistent. ## Acceptance criteria - [ ] The existing Forage/component configuration priority is preserved. - [ ] Shared implementation guidance prefers declarative bean construction only after verifying that it satisfies the requirement for the target versions/runtime. - [ ] Shared review checks flag unnecessary scripted bean initialization and accept a justified script fallback; an unverified alternative is not reported as a confirmed replacement. - [ ] The InfluxDB example produces a declarative factory bean, including supported token conversion and cleanup, without adding a scripting dependency solely to instantiate the client. - [ ] Focused validation covers both a usable declarative factory and initialization that requires a script fallback. Existing transformation-script behavior remains unchanged. - [ ] Updated shared guidance reaches all supported agent installations through the existing distribution mechanism. - [ ] Documentation explains the preference and fallback, with the required companion website update or linked follow-up tracked before closing this issue. ## Website impact **required** — this changes the default generation/review workflow. Document the bean-construction preference and script fallback in `luigidemasi/camel-kit-web`; implement that update in the same workstream or link a website follow-up before closing this issue. ## Reference [Apache Camel 4.22 YAML DSL: factory beans and bean lifecycle methods](https://camel.apache.org/components/4.22.x/others/yaml-dsl.html#_creating_beans_from_factory_bean). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
