Support making IntegrationFlow gateways @Primary

[chrylis]

I am working on decomposing an application that is currently deployed as a monolith but will be separated into services communicating over message queues. I'm using Spring Integration to define in-memory channels for now so that we can migrate them to external queues with adapters.

I have an interface Updater that I'll use as a gateway but that is also concretely implemented in one of the monolith components:

// in shared jar
interface Updater {
  void update(Entity entity)
}

// in component-foo
class UpdaterImpl implements Updater {
  ...
}

When I define an IntegrationFlows.from(Updater) in my configuration, I get a Spring context error because I have multiple Updater beans in the context. The usual approach to fixing this is to mark one of the beans as @Primary, but there doesn't seem to be any way to do that with a DSL integration flow; applying @Primary to the @Bean IntegrationFlow updater has no effect.

It would be useful for primaryness to be propagated to gateway beans created by the DSL. Perhaps the infrastructure could examine the "current bean" definition to see if it's primary and then copy that onto the gateway being constructed?

[artembilan]

I think the @Primary is just a hack to easy solve some design issue.
It is fully OK to have several beans of the same type.
Consider to use a @Qaulifier in the place where you inject beans just by types at the moment.
Another way, specific to this interface-based approach is to have a super- or sub-interface to narrow a visibility.

Also you can do something like this:

@Bean
@Primary
AnnotationGatewayProxyFactoryBean myGateway(MessageChannel flowInputChannel) {
   AnnotationGatewayProxyFactoryBean gateway = new AnnotationGatewayProxyFactoryBean(Updater.class);
   gateway.setDefaultRequestChannel(flowInputChannel);
   return gateway;
}

@Bean 
IntegrationFlow gatewayFlow(MessageChannel flowInputChannel) {
    return IntegrationFlows.from(flowInputChannel)
                     ...
}

I don't think it makes sense to overcomplicate the framework high-level API just to satisfy your project specifics which sound like will go away eventually anyway.

[chrylis]

The problem is that there's no way to express "unless" or "not" in Spring—for example, "without this qualifier", and the subtype approach doesn't address that client consumers use the most abstract form of the interface and don't see any further refinements that might be added in the main context. If there were a way to say "prefer (or even require) the gateway version of this bean", that would be fine, but there isn't.

[artembilan]

@chrylis ,

you didn't answer how workaround with that AnnotationProxyFactoryBean is doing?

I think for consistency with Spring's @Component we will add a @Primary support on the @MessagingGateway.

What you are asking in this issue about Java DSL won't make sense since DSL is much higher in abstraction and ti step a bit away from standard bean definition style to let end-user to concentrate on the business task solution via DSL structure rather than still thinking about dependency injection container.
Plus the DSL is processed a bit later in the configuration phase, so any extra infrastructure hints might not have any effect since their purpose will be ignored already.
This later processing phase, essentially IntegrationFlowBeanPostProcessor may lead to dependency injection expectations by itself.
But we will discuss that in your other issue #3922.

As I said: we just add a @Primary support on the @MessagingGateway as the fix to this issue.

[chrylis]

@Primary combined with the @Bean AGPFB does in fact solve the original use case I made the feature request for. I ran into some further difficulties with dependency resolution and auto-configuration (described in other issues), but for my original request breaking out the @Bean declaration as shown does work. I think having @Primary @MessagingGateway will be helpful for some use cases.