I have a microservice that utilizes a custom binder, CustomBinderA, and a declarative approach. In the code, you can find several classes with annotations like @EnableBinding, @Input, @StreamListener, and so on. Everything works fine.
Recently, I implemented another binder, CustomBinderB, and tested it on a different microservice using the latest functional approach, and everything worked well there too.
Now, I am attempting to integrate the new binder into the previous microservice while still keeping the old one. Every configuration point is enabled, and everything should work. However, I noticed that only the explicitly declared bindings (i.e., those with the @Input annotation) are being instantiated.
So, the only thing I am trying to figure out is: can the functional approach and the declarative approach work together, or is there some way in which, if @EnableBinding is used, the properties related to the functional approach are being ignored?
I tried to combine both the configurations using the multibinder approach.
spring:
cloud
stream:
function:
definition: createOrderConsumer
binders:
CustomBinderB:
type: custom-binder-b
CustomBinderA:
type: custom-binder-a
...
bindings:
createOrderConsumer-in-0:
destination: createOrder
binder: CustomBinderB
outbox:
destination: notifyOrder
binder: CustomBinderA
inbox:
destination: inbox
binder: CustomBinderA
I expected every bindable channel to be instantiated.
However, only the "inbox" and "outbox" channels are being instantiated, which are the ones explicitly declared using the @Input and @Output annotations.
EnableBindingand all related components, such asInputandOutputetc., have been deprecated for a while now and completely removed from the recent versions of the framework (starting with4.0.0). Therefore, we highly recommend to stop usingEnableBindingin your application and migrate completely to the functional style. If you are using a version of Spring Cloud Stream that still supportsEnableBinding, it is not advised to mix both styles in a single application.