Repository navigation
CAMEL-25380: camel-yaml-dsl - Do not log the compact notation warning for the Kamelets of the Kamelet catalog - #27448
Conversation
… for YAML inside a jar The Kamelets of the Kamelet catalog are compact, and every user of timer-source was told to normalize a file inside a jar they cannot change. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m
|
🌟 Thank you for your contribution to the Apache Camel project! 🌟 🐫 Apache Camel Committers, please review the following items:
|
Croway
left a comment
Croway
left a comment
There was a problem hiding this comment.
Thanks for tackling this — the timer-source case is real. I ran a few reproducers against the PR head (71de42e3ad04) and "is it inside a jar" turns out to be a proxy for "is it the user's file" that misfires in both directions:
1. User's own files referenced explicitly are silenced.
A compact route in the application's own jar, loaded via classpath:routes/my-route.yaml, produces no warning. Same for a user's custom Kamelets packaged under classpath:kamelets/ in an uber jar — those are files the user owns and should normalize.
2. …but the same file via a wildcard still warns.
classpath:routes/*.yaml (camel-main style) scans the jar into a PackageScanJarResource with location file:/…/my-app.jar!/routes/my-route.yaml — not classpath:-prefixed, so it warns:
YAML DSL compact notation detected in: file:/…/my-app.jar!/routes/my-route.yaml. …
So the same file warns or not depending on how it's referenced.
3. Non-jar archive protocols still warn.
A classpath resource served via vfs: (WildFly) still logs the "fix this file" warning; same expected for wsjar:, bundle:, Quarkus native resource::
YAML DSL compact notation detected in: classpath:archived/compact.yaml. …
4. Lookup cost on every load.
isInsideJar runs in newYamlDeserializationContext, i.e. twice per resource (pre-parse + parse) and on every reload, even for canonical files that will never warn — 2 lookups for a single canonical route in my reproducer.
Suggestion: decide by origin rather than URL protocol — e.g. suppress for templates loaded via RouteTemplateHelper/KameletRoutesBuilderLoader from the default Kamelet location, and keep warning for user route locations. If the jar check stays, resource.getURI() already resolves classpath URLs (no need to re-derive the path), and it could run lazily inside warnCompactNotationOnce.
Minor:
CompactNotationWarnTestleaves the context on the closedURLClassLoader— restore the original in afinally.- Add a test asserting a non-jar classpath file still warns, so over-silencing is caught.
yaml-dsl.adoc"Compact notation warning" section should mention the exemption.
Reproducer test class available on request.
Claude Code on behalf of Croway
|
🧪 CI tested the following changed modules:
🔬 Scalpel shadow comparison — Scalpel: 11 of 699 tested, 26 compile-only — current: 11 all testedMaveniverse Scalpel detected 11 affected modules (current approach: 11). Skip-tests mode would test 11 modules (2 direct + 10 downstream), skip tests for 26 (generated code, meta-modules) Modules Scalpel would test (11)
Modules with tests skipped (26)
All tested modules (38 modules, 5m 48s total)Total reactor time: 5m 48s
Top 20 slowest modules:
|
…the Kamelet catalog are not warned about Review: "inside a jar" was a proxy for "not the user's file" that misfired both ways (the application's own jar silenced, the same file through a wildcard scan warned, other archive protocols warned) and looked up every resource on every load. Now only a file under kamelets/ in a camel-kamelets jar is exempt, however it was loaded, and that is asked only when the warning is about to be logged. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m
davsclaus
changed the title
|
Thanks @Croway, agreed: "inside a jar" was the wrong test. Reworked in 7b5cf88 to decide by origin, as you suggested:
Claude Code on behalf of Claus Ibsen |
✅ Generated files are up to dateAn earlier CI run reported uncommitted generated changes; the latest run no longer does. |
Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m
2 participants
https://issues.apache.org/jira/browse/CAMEL-25380
Using
timer-source,extract-field-actionorpredicate-filter-actionlogged this on every load and dev-mode reload:That tells the user, or an AI agent reading the log, to normalize a file of the Kamelet catalog, which they can't change.
With this PR the warning is skipped only for a file under
kamelets/in acamel-kameletsjar, however it was loaded:classpath:kamelets/..., a scan of the jar, or a jar nested in a Spring Boot jar. This is checked only when the warning is about to be logged. The application's own files, in its jar or not, custom Kamelets included, are still warned about. The yaml-dsl docs mention the exemption.The catalog itself is made canonical in apache/camel-kamelets#3089. This exemption keeps older pinned Kamelet catalog versions quiet.
Tests in
CompactNotationWarnTest:camel-kamelets-4.22.1.jaris not warned about. This test fails without the change.my-app.jaris warned about.The class loader is restored after each test. camel-yaml-dsl passes 461 of 461.
🤖 Generated with Claude Code
https://claude.ai/code/session_01STT6whBgK1AqsSsUKrnE8m