Improve documentation for <int:wire-tap> about expected behaviour [INT-4014]

[spring-operator]

Manuel Jordan opened INT-4014 and commented

Hello

When I work with:

<int:channel id="channel"
                    datatype="com.manuel.jordan.message.Message" >
        <int:queue capacity="4"  />
        <int:interceptors>
                <ref bean="messageChannelInterceptor" />
        </int:interceptors>
</int:channel>

My own bean which extends ChannelInterceptorAdapter, I am able to intercept
the send and receive moments (except for SubscribableChannel)

Until here I am ok.

But when I use:

<int:channel id="channel"
                datatype="com.manuel.jordan.message.Message" >
     <int:queue capacity="4"  />
     <int:interceptors>
          <int:wire-tap channel="logger"/>
     </int:interceptors>
</int:channel>
          <int:logging-channel-adapter id="logger" 
                                                  level="INFO"
                                                  log-full-message="true"							     
                                                               />	

It only works or intercepts about just only the send, all about the receiver does not happens (I am talking about for non-SubscribableChannel)

My point is, I have assumed that <int:wire-tap> should work for sender/receiver (in this case for a QueueChannel) but only works for sender

Therefore:If it is the expected behaviour, I suggest include that explanation how a note in Wire Tap

---

Affects: 4.2.GA, 4.2.5

[spring-operator]

Artem Bilan commented

I don't see reason to add anything to the Reference Manual, unless the link to the canonical EIP Wire Tap pattern:

Insert a simple Recipient List into the channel that publishes each incoming message to the main channel and a secondary channel.

Although we have that one already in another place: 4.1.3 Channel Interceptors

For your understanding:

The WireTap only "wire-tap" a message to another channel only when that message comes to the channel - send operation. It does not make sense to "wire-tap" the same message again on receive action, because the receive isn't possible without the previous send. When we perform receive, we assume that message is already in the channel. In this case QueueChannel.

So, I'd consider this ticket as "Work as Designed" and close.

And recommend for you EIP Book to read, first of all :)

[spring-operator]

Manuel Jordan commented

Hi Arlem

Thanks by the explanation:

If is not is critical, why not include how a note your explanation

The WireTap only "wire-tap" a message to another channel only when that message comes to the channel - send operation. It does not make sense to "wire-tap" the same message again on receive action, because the receive isn't possible without the previous send. When we perform receive, we assume that message is already in the channel. In this case QueueChannel.

And indicate that the Channel Interceptor is more complete or 'powerful'

And recommend for you EIP Book to read, first of all

Yes, I am reading that book by parts... thanks

[spring-operator]

Artem Bilan commented

Well, as I said: I don't see reason to say anything else.

Since our WireTap is fully based on the premise of the canonical EIP pattern, it implies that our behavior is similar.
Yes, if that would be otherwise we'd mention that in the Reference Manual.

The other (custom) Channel Interceptors are more "powerful", because they may do fully different logic.

Otherwise we are going to replicate half the Internet into our Reference Manual.

Thanks and sorry, but I insist to close this like "Work as Designed" and go ahead with more critical work around.

[spring-operator]

Manuel Jordan commented

Hi Artem

Ok, I understand. Proceed to close how ''Work as Designed".