Open aldettinger opened 3 days ago
We generally try to avoid named beans as much as possible.
In the specific case of AiService, why use the name of the bean and not the type?
Along the years, it's common habit for camel users to reference beans by name and to a less extent by type. In the specific case of AiService, there is camel bug or maybe limitations preventing the resolution by interface. This could be investigated for sure but that's actually another topic.
Back to resolution by name, if we consider it's a bad design in the specific case of AiService, then maybe we prefer to close this ticket ? What do you think ?
If you want to add opt-in support for @Named
like you propose, that's fine - we can have it
It could be worth exploring, just need a bit more info about opt-in support. How is opt-in usually implemented ? Maybe we have an example somewhere please ?
I don't have any examples, but in this case we likely just need to read the annotation and pass the value to ExtendedBeanConfigurator
.
https://github.com/quarkiverse/quarkus-langchain4j/blob/bc7d6c05f942f94de0cd052292b0e3d456ab4f16/core/deployment/src/main/java/io/quarkiverse/langchain4j/deployment/AiServicesProcessor.java#L469 is where the bean is built, so if you include (an optional) bean name in DeclarativeAiServiceBuildItem
, then you can pass it to the bean creation process.
Enabling AI services bean resolution by EL name may improve user experience in Apache Camel.
Like we could define an AI service like below:
And then use it from a Camel route like that:
One way to implement could be to copy the
@Named
annotation value when quarkus-langchain4j generates the AI service implementation.Does it sound a valid idea to start working on a pr ? I guess it is valid to assume that there will forever be only a single AI service implementation class per AI service interface ? Maybe later on, it makes sense to also implement resolution by interface type ? and by @Identifier ?