Croway commented on code in PR #25354:
URL: https://github.com/apache/camel/pull/25354#discussion_r3719750416


##########
components/camel-spring-parent/camel-spring-ai/camel-spring-ai-chat/src/test/java/org/apache/camel/component/springai/chat/SpringAiChatToolNamesTest.java:
##########
@@ -0,0 +1,182 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ *      http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.camel.component.springai.chat;
+
+import java.util.Arrays;
+import java.util.List;
+
+import org.apache.camel.Exchange;
+import org.apache.camel.builder.RouteBuilder;
+import org.apache.camel.test.junit6.CamelTestSupport;
+import org.junit.jupiter.api.Test;
+import org.mockito.ArgumentCaptor;
+import org.springframework.ai.chat.messages.AssistantMessage;
+import org.springframework.ai.chat.model.ChatModel;
+import org.springframework.ai.chat.model.ChatResponse;
+import org.springframework.ai.chat.model.Generation;
+import org.springframework.ai.chat.prompt.ChatOptions;
+import org.springframework.ai.chat.prompt.Prompt;
+import org.springframework.ai.model.tool.ToolCallingChatOptions;
+import org.springframework.ai.tool.ToolCallback;
+import org.springframework.ai.tool.ToolCallbackProvider;
+import org.springframework.ai.tool.annotation.Tool;
+import org.springframework.ai.tool.method.MethodToolCallbackProvider;
+
+import static org.assertj.core.api.Assertions.assertThat;
+import static org.mockito.ArgumentMatchers.any;
+import static org.mockito.Mockito.mock;
+import static org.mockito.Mockito.verify;
+import static org.mockito.Mockito.when;
+
+/**
+ * Unit test for selecting tools by name via the {@code toolNames} option and 
the
+ * {@link SpringAiChatConstants#TOOL_NAMES} header.
+ *
+ * Spring AI 2.0 removed {@code 
ChatClient.ChatClientRequestSpec.toolNames(String...)} and the Spring bean based
+ * {@code SpringBeanToolCallbackResolver}, so the component resolves the names 
itself. These tests capture the
+ * {@link Prompt} handed to the {@link ChatModel} and assert which tool 
callbacks made it through.
+ */
+public class SpringAiChatToolNamesTest extends CamelTestSupport {

Review Comment:
   Fixed in ea39bdf — class and the four `@Test` methods are now 
package-private. The overrides (`doPreSetup`, `createRouteBuilder`, 
`configure`) keep the supertype visibility per the JLS 8.4.8.3 carve-out in 
AGENTS.md, and the `@Tool` holder classes stay `public` so Spring AI can 
reflect over them. Test still passes 4/4.
   
   _Claude Code on behalf of Federico Mariani_



##########
components/camel-spring-parent/camel-spring-ai/camel-spring-ai-chat/src/main/java/org/apache/camel/component/springai/chat/SpringAiChatProducer.java:
##########
@@ -994,6 +1005,49 @@ private List<ToolCallback> getToolCallbacksForTags(String 
tags) {
         return toolCallbacks;
     }
 
+    /**
+     * Resolve the configured tool names to {@link ToolCallback} instances.
+     * <p>
+     * Spring AI 2.0 removed {@code 
ChatClient.ChatClientRequestSpec.toolNames(String...)} and the Spring bean based
+     * {@code SpringBeanToolCallbackResolver}, so the names are resolved here 
instead. Each name is looked up, in order,
+     * against:
+     * <ol>
+     * <li>a {@link ToolCallbackResolver} bound in the Camel registry - Spring 
Boot applications get Spring AI's
+     * auto-configured resolver, which covers {@link ToolCallback} and {@link 
ToolCallbackProvider} beans</li>
+     * <li>the tool callbacks already available to this endpoint, i.e. the 
ones discovered from {@code tags} and the
+     * ones configured via {@code toolCallbacks}, matched on their tool 
definition name</li>
+     * <li>a {@link ToolCallback} bound in the Camel registry under that 
name</li>
+     * </ol>
+     *
+     * @param  names                    the tool names to resolve
+     * @param  availableByName          the callbacks already available to 
this endpoint, keyed by tool name
+     * @return                          the resolved callbacks, never {@code 
null}
+     * @throws IllegalArgumentException if a name cannot be resolved
+     */
+    private List<ToolCallback> resolveToolCallbacksByName(List<String> names, 
Map<String, ToolCallback> availableByName) {
+        final ToolCallbackResolver resolver = 
getEndpoint().getCamelContext().getRegistry()
+                .findSingleByType(ToolCallbackResolver.class);
+
+        final List<ToolCallback> resolved = new ArrayList<>(names.size());
+        for (String name : names) {
+            ToolCallback callback = resolver != null ? resolver.resolve(name) 
: null;

Review Comment:
   Good catch to raise it — I did verify the contract, so I have left it as-is.
   
   `ToolCallbackResolver.resolve(String)` declares its return type as 
`@org.jspecify.annotations.Nullable` (visible as a 
`RuntimeVisibleTypeAnnotations` entry on the interface method in 
`spring-ai-model` 2.0.0), so returning `null` for an unknown name *is* the 
documented contract rather than an implementation detail. Spring AI 2.0 
annotated the whole API surface with JSpecify, which is what makes this 
checkable now. `DelegatingToolCallbackResolver.resolve` iterates its delegates 
and returns `null` once none match, and `StaticToolCallbackResolver` returns 
`null` from its map lookup.
   
   I would rather not wrap it in a `try/catch`: a resolver that throws on an 
unknown name is violating the annotated contract, and swallowing that would 
turn a genuine misconfiguration (say a resolver whose backing service is 
unreachable) into a silent fallback to a different tool, or into the "Cannot 
resolve tool name" error further down, which would point at the wrong cause. 
Letting it propagate surfaces the real problem. Happy to revisit if a concrete 
third-party resolver turns up that throws.
   
   _Claude Code on behalf of Federico Mariani_



-- 
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