Configuring Spring Integration channels without XML

I’ve been looking at some messaging frameworks lately and trying to find something that’s not too obtrusive. Spring Integration seems straightforward, plays nicely with our other Spring stuff, and runs in your application, which is a plus for us, but it’s hard to find simple examples to get started with, especially if you want to avoid xml configuration.

Spring makes it hard to totally skip all xml, but here’s an attempt to configure a pollable channel and a subscribable channel with as little xml as I can get away with.

First, the Maven pom has these dependencies:


The configuration xml is just a pointer to the java configuration (the TestAppConfig class).

In java, we configure the context with a QueueChannel, a PublishSubscribeChannel, and a TaskScheduler.

I didn’t see a simple implementation of MessageHandler, so I wrote a test handler that just prints out messages.

For this demo, the channels and their consumers are squeezed into one main method. We get the channels out of the Spring context, set up consumers to listen to them, then send out simple string messages to each of the channels.

Try running it and you should see the output of all the consumers as they receive the messages and let the message handler process them.

Handler A; [Payload=Message on the pollablechannel][Headers={timestamp=1318972120696,id=9db9d54a-a2d3-4396-bfac-632c3b4b861f}]
Handler B; [Payload=Message on the subscribablechannel][Headers={timestamp=1318972120697,id=5c918d28-4044-4b52-9e36-60f2498c5616}]
Handler C; [Payload=Message on the subscribablechannel][Headers={timestamp=1318972120697,id=5c918d28-4044-4b52-9e36-60f2498c5616}]

Woohoo! Not that useful in itself, but it shows the basic idea of channels and consumers.

This entry was posted in java, software and tagged . Bookmark the permalink.

4 Responses to Configuring Spring Integration channels without XML

  1. elder says:

    Thanks for that – it really helped. I’m also looking for a way to use Spring Integration more programatically i.e. not relying on a ‘static’ XML configuration. One question (being new to Spring as a whole, it may be not be a sensible one), but is there any reason to prefer creating SI objects ‘in the raw’ like e.g. PollingConsumer in the example, rather than via a BeanDefinitionFactory and asserting them into the Spring context (as I’ve seen elsewhere)? Aside from the DI aspects, I’m wondering if I might miss out on some lifecycle stuff if my objects are not in the context? Or maybe you’ve just simplified for the sake of the example…? thanks.

    • tborthwick says:

      Glad it was useful. I just tried to make things a little more explicit for the sake of the example. I don’t think there’s any benefit to doing it this way over using a factory and inserting objects into the context.

  2. Leo says:

    Hi, thanks for the example. Also, TestAppConfig above seems to be truncated.

Leave a Reply

Your email address will not be published. Required fields are marked *