Remote JMS with WildFly Swarm

I'm blogging about WildFly swarm again? Short version is: I needed a test for remote JMS access and refused to setup something complex like a complete application server. The idea was to have a simple WildFly Swarm application which has a queue and a topic configured. Both should be accessible remotely from a standalone Java application. While the topic receives messages a Message Driven Bean (MDB) dumps the output to the console. The queue is filled with random text+timestamp messages by a singleton timer bean.
Turned out, that WildFly Swarm can do it, but for now only in the snapshot release.

The code
Find the complete code on my GitHub repository. It's not the most beautiful thing I have written but it actually shows you the complete configuration of Swarm with the relevant security settings, and the construction of the queue and the topic. In short the MessagingFraction needs the relevant security settings with remote access enabled and it also needs to define the remote topic. The NamingFraction needs to enable the remote naming service and finally the ManagamentFraction needs to define authorization handler.

How to run the example
To run the server, you can just use 'mvn wildfly-swarm:run' after the startup, you see the timer bean starting to emit messages to the queue:

2016-08-05 08:44:48,003 INFO  [sample.SampleQueueTimer] (EJB default - 5) Send: Test 1470379488003

2016-08-05 08:44:49,005 INFO  [sample.SampleQueueTimer] (EJB default - 6) Send: Test 1470379489005

If you point your browser to http://localhost:8080/ you can trigger a single message being send to the topic. This also get's logged to the console:

2016-08-05 08:44:36,220 INFO  [sample.SampleTopicMDB] (Thread-250 (ActiveMQ-client-global-threads-859113460)) received: something

The real magic happens, when you look at the standalone Java client. It performs the relevant JNDI lookups and creates the JMS connection with user and password, the session and the producer and finally produces and sends a text message.
More about the "why the hell does he needs Java EE again" in some upcoming blog posts ;)

Credits
A super big thank you goes out to Ken Finnigan who fixed the issue I ran into literally over night!