knockknock10 commented on issue #6910: URL: https://github.com/apache/camel-k/issues/6910#issuecomment-6708000603
> One additional requirement we can consider for the design of this feature. Let's consider the following Integration code: > > ``` > spec: > flows: > - beans: > - name: rabbitConnectionFactory > type: org.springframework.amqp.rabbit.connection.CachingConnectionFactory > properties: > host: my-rabbitmq.my-ns.svc > port: 5672 > username: admin > password: admin > - route: > from: > uri: spring-rabbitmq:my-exchange?queues=my-queue&routingKey=my-key > steps: > - to: log:info > traits: > camel: > properties: > - camel.component.spring-rabbitmq.connection-factory=#rabbitConnectionFactory > ``` > > It could even be Java or XML, but let's use YAML DSL as a reference. In the scaler mapping we should be able to identify the connection bean name `#rabbitConnectionFactory`, then, we should be able to scan the code and identify the bean properties and maybe use those one to automatically configure the scaler. > > [@knockknock10](https://github.com/knockknock10) I think this approach may be partially solving the doubts we were having about the complexity of scanning the registry. We cannot scan at runtime, but, if we have enough info at build time, then, we should be able to automatically configure the scaler. WDYT? hello @squakez I think this is worth exploring. In this example, we already have the bean declaration in the Integration source and its reference in the component property, so we may not need to inspect the runtime registry at all. The part I want check is how we can connect these two during the existing build-time metadata extraction, and whether the bean properties are actually sufficient for the corresponding scaler configuration. I'd start with the YAML DSL case you shared and keep Java/XML as something to evaluate separately. We should also be careful with values coming from secrets or unresolved placeholders, since those shouldn't be treated as ordinary resolved properties. I'll update the design around this example and check how it fits into the existing KEDA mapping flow. -- 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]
