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]

Reply via email to