IntegrationFlow to extend SmartLifecycle

[lafual]

With reference to the comments to the solution of Programmatically start and stop certain IntegrationFlows in Spring Integration?
the interface IntegrationFlow should extend SmartLifeCycle as IntegrationFlow does not provide (for example) stop() and start().

The two implementing classes of IntegrationFlow namely IntegrationFlowAdapter StandardIntegrationFlow already implement SmartLifecycle - so it should be possible to make this fit.

[artembilan]

Well, Lifecycle is not designed for the IntegrationFlow in general. Or even better to say the IntegrationFlow is not always Lifecycle.
To do that right for the dynamically registered flows we need to deal with their context - IntegrationFlowContext. You inject it whenever you need to deal with dynamic flows and do this:

	/**
	 * Obtain an {@link IntegrationFlowRegistration} for the {@link IntegrationFlow}
	 * associated with the provided {@code flowId}.
	 * @param flowId the bean name to obtain
	 * @return the IntegrationFlowRegistration for provided {@code id} or {@code null}
	 */
	IntegrationFlowRegistration getRegistrationById(String flowId);

and call its start()/stop(). I don't think the IntegrationFlow contract is the right pace to carry a Lifecycle callback. By definition the IntegrationFlow is just a logical container which in most cases is not an end-user API: or you should deal with individual components independently or use an appropriated API like IntegrationFlowContext. Fully similar what we have with the mentioned RabbitListenerEndpointRegistry.

I tended to close this as Works as Designed, but I'll wait for your feedback.

Thanks

P.S. We probably need to improve this section in docs: https://docs.spring.io/spring-integration/docs/current/reference/html/dsl.html#java-dsl-runtime-flows to make this more clear, but still I'm against bringing Lifecycle into an IntegrationFlow interface.

[garyrussell]

I agree; I just realized it would break lots of code since it will no longer be a @FunctionalInterface.

[lafual]

In hindsight I agree too. It would not make sense to stop anything other than Inbound Channel Adapter. Maybe a new interface InboundIntegrationFlow extends IntegrationFlow, SmartLifecycle? Gary says that it is a @FunctionalInterface so this probably would help matters.

You are the authors. This suggestion is not essential for me. You can close this case if you wish.

[artembilan]

Yeah... As I said: not enough justification to expose a Lifecycle contract on the IntegrationFlow for end-user interaction.
The dynamic flows should be controlled via IntegrationFlowContext.
Everything else is done automatically by the framework transparently for end-users.

[artembilan]

Closed as Won't Fix.

[jbmbcz]

Just a note: see the docs (https://docs.spring.io/spring-integration/docs/current/reference/html/dsl.html#java-dsl-basics):

However the bean for IntegrationFlow can be autowired as a Lifecycle to control start() and stop() for the whole flow which is delegated to all the Spring Integration components associated with this IntegrationFlow

This seems to be in contradiction with what @artembilan has said, maybe the docs should be updated? or am I wrong?

[artembilan]

The docs are correct. The IntegrationFlow @Bean becomes as a Lifecycle according to its StandardIntegrationFlow implementation. But that's not always fact when we create flows dynamically.
More over the IntegrationFlow was designed more like a placeholder for lambda definition being a @FunctionalInterface, so end-user would just concentrate on the flow definition, rather than thinking how to implement those lifecycle contracts.

It's even probably better to remove that sentence from the docs to fully eliminate a possible abuse for the Lifecycle aspect of this interface implementation.