Spring RabbitMQ cheat sheet
From DarkWiki
Sending to topics
On the Producer side (the one that raises the events) we create our TopicExchange, giving it a sensible name:
import org.springframework.amqp.core.TopicExchange;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class EventProducerConfig {
@Bean("eventExchange")
public TopicExchange eventExchange() {
return new TopicExchange("eventExchange");
}
}
It can then be used by our Producer to send event notifications to anyone who subscribes to the exchange:
@Component
public class EventProducer {
private final RabbitTemplate rabbitTemplate;
private final Exchange exchange;
public EventProducer(RabbitTemplate rabbitTemplate,@Qualifier("eventExchange") Exchange exchange) {
this.rabbitTemplate = rabbitTemplate;
this.exchange = exchange;
}
public void signal(String eventId,EventMessage message) {
rabbitTemplate.convertAndSend(exchange.getName(), eventId, message);
}
}
You can then send EventMessage payloads with event ids such as "event.user.created" or "event.user.deleted" using the signal method.
Listening for events
This shows how to use two dynamically created queues (one for created and one for deleted events). They will not be persistent (won't survive restart).
@RabbitListener(bindings = @QueueBinding(
value = @Queue,
exchange = @Exchange(value = "eventExchange", type = "topic"),
key = "event.#.created"))
public void consumeCreated(EventMessage message) {
// ...
}
@RabbitListener(bindings = @QueueBinding(
value = @Queue,
exchange = @Exchange(value = "eventExchange", type = "topic"),
key = "event.#.deleted"))
public void consumeDeleted(EventMessage message) {
// ...
}
This pattern is fine for one-offs, but generally it is better to declare your queues elsewhere. This allows them to be properly configured at some point in the future.