luigidemasi commented on code in PR #24065:
URL: https://github.com/apache/camel/pull/24065#discussion_r3426889681
##########
dsl/camel-yaml-dsl/camel-yaml-dsl-common/src/main/java/org/apache/camel/dsl/yaml/common/YamlDeserializationContext.java:
##########
@@ -120,14 +141,204 @@ protected Optional<ConstructNode>
findConstructorFor(Node node) {
@Override
public void start() {
+ loadResolvers();
+ }
+
+ private void loadResolvers() {
ObjectHelper.notNull(camelContext, "camel context");
-
this.resolvers.addAll(getCamelContext().getRegistry().findByType(YamlDeserializerResolver.class));
+ if (resolversLoaded) {
+ return;
+ }
+
+ addResolverEntries(loadResolversFromClasspath());
Review Comment:
@jamesnetherton I agree that Camel Quarkus should not need this runtime
classpath discovery path if it can discover and configure the resolvers at
build time.
**I think the critical bit is that this should not be a user-facing
“suppress classpath loading” switch.**
A cleaner fix would be to introduce a Camel-owned discovery/provider SPI,
for example `YamlDeserializerResolverProvider`, registered as a Camel context
plugin.
The YAML deserialization context would then:
1. Ask the provider for automatically discovered resolvers.
2. Load explicit registry resolvers separately, as it does today.
The default Camel provider would preserve the current behavior by reading:
```text
META-INF/services/org/apache/camel/YamlDeserializerResolver
```
and instantiating those classes through the Camel injector.
Camel Quarkus could register its own provider at build time, returning the
resolvers discovered during augmentation, without doing runtime
ClassLoader.getResources(...) or service-resource scanning.
This should avoid breaking existing users because:
- YamlDeserializerResolver itself remains unchanged.
- Existing service descriptor based discovery continues to work in plain
Camel.
- Explicit registry resolvers remain supported.
- Quarkus/native gets an authoritative build-time integration point
instead of a runtime suppression flag.
So I propose to adjust the PR in that direction unless you see a better
Camel Quarkus integration point.
_AI-generated draft by Claude on behalf of ldemasi._
--
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]