SubscribableChannel test helper?

[vromero]

Does it exist something like muleClient in spring integration?

I would like to client.getResponse(subscribableChannel, timeout) so I can easily unit test fetching messages from channels.

At the moment I'm doing this (that is wrong in so many ways and wont probably work in a queued channel at all) :

expectedChannel.subscribe(new MessageHandler() {
@Override
public void handleMessage(Message<?> message) throws MessagingException {
assertThat(message, hasPayload(payload));
System.err.println("CALLED");
}
});

inputChannel.send(MessageBuilder.withPayload(paylo ad).build());
try {
Thread.sleep(5000);
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}

[oleg.zhurakousky]

Just use QueueChannel. Than you can executed receive() on it. Is that what you are looking for?

[vromero]

I was looking for something like this (a receive with timeout for SuscribableChannel).

That should help to have tests without sleeps at the end.

[oleg.zhurakousky]

Well you don't need any sleep since QueueChannel.receive() also comes with timeout. For example:

QueueChannel channel = context.getBean(...);
Message<?> message = channel.receive(10000); //will wait for message for up to 10 seconds before returning null

Also, you can look at MessagingTemplate which has a lot of send/receive type methods: http://static.springsource.org/sprin...annel-template

Also the gateway is yet another approach which allows you completely POJO way of dealing with request/reply message flows: http://static.springsource.org/sprin...#gateway-proxy

[vromero]

I'm not keen, at the moment, to change to QueueChannel. I want to test the orchestration itself, not just a service, so the MessagingTemplate sounds like the way to go. Looking at the documentation it looks awesome, except for something that puzzles me out :
public Message<?> receive(final PollableChannel<?> channel) { ... }

receive only works with PollableChannel ?

[oleg.zhurakousky]

Victor

Yes, receive() only works with PollableChannel since by definition only PollableChannel has capabilities to buffer messages while still maintaining the semantics of P2P messaging contract (for each message there can only beone consumer). This means its is holding messages until a consumer asks for it. The flip side of it are the SubscribableChannels which DO NOT buffer messages. The SubscribableChannel work together with MessageDispatcher to dispatch arriving messages according to the message exchange contract represented by a particular SubscribableChannel (P2P or Pub/Sub). The P2P type channel (e.g., DirectChannel, ExecutorChannel etc.) will require that there should be a subscriber consuming messages otherwise you'll see MessagingException telling you that "dispatcher has no subscribers" where with Pub/Sub channels (e.g., PublishSubscribeChannel) each Message wil be dispatch to as many subscribers as present. If 0 the message will be discarded etc.
So the bottom line is:
You poll from PollableChannel
You subscribe from SubscribableChannel

I understand you come from the Mule background and trying to look at Spring Integration as something similar. Similar we might be but not identical. If you go through the Enterprise Integration Patterns (which we treat as specification for Spring Integration) http://www.eaipatterns.com/ you may notice how misrepresented some of the EIP concepts are in Mule. That is one of the reason why we have more and more people and organizations migrating from Mule to Spring Integration

You may also be interested in this case study form a large internet company
http://www.springsource.com/files/up...ntegration.pdf