JavaFX2 Message Broker Client For The Rest Of Us

Developers of systems for Enterprise Integration often need to interact with a message broker in order to view messages or send messages to queues or topics. The problem is, a client application which does that is not always readily available.

Now there is one!

You can now use the MQConsole client application (at least for Apache ActiveMQ and HornetQ). MQConsole is an open source application that I started to develop using a maven multi-module project. Each broker support in developed as a maven module and shares the same user interface with the others. The source code is available on Github (here) and the binary distributions for Windows and Mac are available on Bintray (here).

main window - broker destinations

The main window shows a table with information about the queues and topics found in the message broker. There are a number of actions available if you right-click on any queue or topic:

• See the list of messages in a queue or topic
• View the details of a specific message
• Send a new message to a queue or topic
• Subscribe to a queue or topic and display messages as they arrive there.

send a new message window

When sending a new message, you can opt for a request/response scheme by ticking the "Has Response" box. In this case, the application will wait for a response and displays the reply message in the "Response" tab.

Window displaying a received message

When you subscribe to a channel or topic in the main window, a window displaying one message pops up every time a new message arrives.

This window can also be opened to view the details of a message in a message list.

The message details displayed are the message headers and its payload as long as its non binary.

Please download from Bintray and see the Github site to create an issue with your improvement suggestions

Requires Java 8 update 20 or a newer version.

Messaging Setup using spring on wildfly and hornetq

WildFly 8 is almost final and I bet some people are wanting to upgrade from JBoss. That is our case here at my job and our new setup is like this:

We have App 1 (spring-integration app) running on wildfly 1 and App 2 (spring server app) running on wildfly 2. Both wildfly are standalone instances.

App 2 publishes messages to its wildfly embedded hornetq broker.

App 1 listens to messages published on the hornetq at wildfly 2 using a durable subscription and the remote connection defined in wildfly 1.

First lets look at App 2.

• application-2-context.xml is the snippet of a spring application-context that configures a JmsTemplate to send messages to the hornetq topic.
• Standalone2.xml is the messaging-subsystem part of the wildfly 2 server configuration file:

I added a JMS Topic, disabled security for connections to the embedded hornetq broker and allow Gests to create durable queues. See the inline comments.

Now lets look at App 1.
In node 1, the wildfly server configuration file is partially displayed here in two separate files:

• socket-binding@standalone1.xml shows the socket binding part of the wildfly configuration and the definition of the socket used to connect to the hornetq broker in Node 2.
• messaging@standalone1.xml shows the messaging subsystem - defines the netty connector "netty-node2" and the pooled connection factory that facilitates the durable subscriptions to the EventsTopic on Node 2 - note the client-id definition.
• application-1-context.xml is the snippet of a spring-integration application-context that configures the necessary beans to direct the messages published to EventsTopic ti a specific message channel.