INT-4457: Make log() in the end as reply-aware

[artembilan]

JIRA: https://jira.spring.io/browse/INT-4457

When an IntegrationFlow is reply-based (we expect a reply in the
beginning) and log() (or wireTap()) is used in the end, we are
forced to add an empty bridge() in the end to ensure a replyChannel
header routing

• Fix IntegrationFlowDefinition to add enrichHeaders() in the end
  to populate a nullChannel as a replyChannel header if that is missed
  in the request message headers.
  This way we cover both use-cases when we expect reply from the flow and
  when it is used as a one-way scenario
• Improve a HeaderEnricher do not create a new Message if there are
  no new headers to add/remove
• Remove a note from the dsl.adoc about now redundant bridge() after
  log()
• Resolve TODO in the .handle() paragraph

[garyrussell]

We should probably add a comment here to explain why - I will do it when merging.

[artembilan]

Yeah... Makes sense.
This is really a cool trick since we did a replyChannel resolution against a reply message as fallback.
So, this way the HeaderEnricher will be able to produce its reply to that nullChannel only if there is no a replyChannel in the request message.

However I'm starting to think that this should be something like new NullChannel() - definitely an internal matter and free from any management and metrics.

WDYT?

[garyrussell]

Hmmm... while writing the comment, it made me think that we have a problem here...

This logic will mask a "lost reply channel mistake".

Right now if we have

.from(gateway)
.transform() // this transformer has a bug - removes the replyChannel header.
.wiretap()
.bridge()
.get()

We'll get the infamous no output-channel or replyChannel header available error and quickly determine the problem.

With this change, we'll no longer get the error and the gateway will hang or timeout.

I think this might cause us a bunch of Stack Overflow grief.

[artembilan]

I see what you mean.

To choices: close as "Works as Designed" or spend more time to think what could we do. For example to figure out some how how to intercept a replyChannel evaluated at runtime...

[garyrussell]

I had a couple of ideas:

1. Detect that the flow starts with a gateway and automatically add a bridge to nowhere - I rejected this because someone could add a replyChannel header mid-flow.
2. Add a new property to the wireTap and log specs - something like .log().andReply(), which would only be allowed on the last component.

But WAD works for me too.

[garyrussell]

I guess .andReply() would just be a synonym for bridge() - but maybe semantically more pleasing.

[artembilan]

Well, the flow might not start from the gateway, but simple channel.
That channel can be used for sending from the one-way scenario, as well as from the gateway one, on the other hand.
So, this our flow is not aware of the upstream in advance.

I believe we can restore code because it is stable and just document how to be in such a double case as long as the replyChannel propagation is supplied properly during the flow...

Another option do not allow to register log/wire-tap in the end. As far as it is a channel interceptor there really should be an channel to apply to...

[artembilan]

How about just logAndReply() which is indeed a synonym for the log().bridge() and represent's no-op when is used in the middle?

The double situation mentioned above is fully not related to the story and should be revised from the target application perspective.

[garyrussell]

logAndReply() sounds good - couldn't we detect it's used mid-flow by checking the previous component?

[garyrussell]

Merged as 055e9a4