Wire-Tap during the response

[Mark Fisher]

Well, I would probably consider whether the logging is really a "first class" component of the system... even if it is *only* logging. The wire-tap is typically something you would add or remove without affecting the overall flow. Instead of a dummy service and wire-tap, you could just add <logging-channel-adapter> with its input-channel set to your "acResponseChannel". Is there some reason you want to avoid that?

[toramanan]

I wont be able to use logging-channel-adapter since my requirement is to publish to a JMS system. My understanding for logging-channel-adapter is for logging to a file system or other using log4j/commons logging.

[Mark Fisher]

Right. So then, you can use outbound-channel-adapter as a regular endpoint connected to acResponseChannel instead of configuring it on a wire-tap channel. Can you explain why you are trying to avoid that? If it's not an optional part of the flow that could be removed, then it probably should not be connected via wire-tap.

[toramanan]

Hi,

The main feature of the acResponse channel is to send back a SOAP Response back to the client. The meta-data about this process is collected and published to an external system through JMS is more like a "MONITOR" about the process.
So I was thinking Wire-Tap is a very good fit here because :
1. The processing will happen outside the context of the core processing flow. Although true async in SI can be achieved only using <task-executor>. I was thinking by default Wire-Tap will be doing it in a seperate thread to attain "independence", but i was wrong.
2. By adding a regular channel interceptor forces me to write some plumbing code in publishing to a jms system. By using wire-tap and an adapter, reduces the code to zero and at the sametime my original Message<Soap Response> is untouched.