cli4clj Version 1.3.2 – New: Embedded CLIs

In this post, I announce cli4clj version 1.3.2 and write a bit about the newly added functionality for creating embedded Command Line Interfaces (CLIs). For those unfamiliar with cli4clj: the aim of cli4clj is to ease the implementation of simple interactive CLIs for Clojure applications.

The original and still primary focus of cli4clj is on implementing interactive CLIs intended to be used in interactive terminals/shells. However, in one of my other applications, I needed an interactive CLI that can be used via network, actually via a Message-oriented Middleware (MoM).

The primary aspect in the CLI via network use case, from the cli4clj perspective, is that cli4clj leverages jline for handling interactive input from a terminal/shell. In the CLI via network use case, however, input cannot be read from an interactive terminal/shell.

In the concrete scenario of using an MoM, I wanted to send commands via messages and receive the output via corresponding reply messages. Furthermore, I wanted to use the existing MoM infrastructure without the need of opening yet another socket. Hence, networked CLIs such as nREPL did not appear as a good match to me.

Furthermore, I wanted to re-use the same map-based approach for configuring the jline-based CLI for the “embedded” CLI. The reason for this is that this will allow to easily switch between a jline-based and an embedded CLI or use both at the same time, e.g., when an application is intended to be used interactively in a terminal and, at the same time, the same functionality should be exposed via network. Moreover, I wanted to make the new “embedded” CLI generic such that it can also be used in other places.

The embedded CLI functionality uses the map-based cli4clj configuration format and creates a “CLI-function” instead of an interactive input. The generated function accepts a string of commands and arguments as input and returns the string result of “executing” the provided input. Thereby, the string result is the output that was produced as a result of executing the supplied command and arguments string.

Below, an example for using the embedded CLI functionality is shown. The example was executed in the cli4clj project in a “lein repl”. In order to illustrate that the output is really returned as string from the “CLI-function” I used the indirection of putting the results in the “ret” var and showed them by printing the value of “ret”.

cli4clj.example=> (use 'cli4clj.cli)
cli4clj.example=> (def cli-opts {:cmds {:print {:fn #(println %)} :divide {:fn (fn [x y] (/ x y))}}})
cli4clj.example=> (def cli-fn (embedded-cli-fn cli-opts))
cli4clj.example=> (def ret (cli-fn "print foo"))
cli4clj.example=> ret
cli4clj.example=> (def ret (cli-fn "divide 4 2"))
cli4clj.example=> ret
cli4clj.example=> (def ret (cli-fn "divide 4 0"))
cli4clj.example=> ret
"ERROR: Divide by zero"
cli4clj.example=> (def ret (cli-fn "bar"))
cli4clj.example=> ret
"ERROR: Invalid command: \"[bar]\". Please type \"help\" to get an overview of commands."
cli4clj.example=> (def ret (cli-fn "help"))
cli4clj.example=> ret
"divide\n\n\nhelp [? h]\n\tShow help.\n\tDisplay a help text that lists all available commands including further detailed information about these commands.\n\nprint\n\n\nquit [q]\n\tQuit the CLI.\n\tTerminate and close the command line interface."
cli4clj.example=> (println ret)
help [? h]
 Show help.
 Display a help text that lists all available commands including further detailed information about these commands.
quit [q]
 Quit the CLI.
 Terminate and close the command line interface.

Besides adding the embedded CLI functionality, I also fixed some issues, as you can see in the version number. However, as things usually go with adding new functionality, even though it was tested and implemented following test-driven development, I likely added new bugs as well. So, whenever you spot a problem, just let me know.

I hope cli4clj is useful for you. I am always happy about constructive feedback and comments.

Posted in cli4clj, Libs. | Tagged , , | Leave a comment

bowerick 2.1.0 Released

In this post, I announce the release of bowerick 2.1.0. Before going into more detail, the summary of changes is as follows:

  • Added functionality for advanced message handling for message producers and consumers.
  • Added a built-in test message/event producer for easing experiments and demonstrations.
  • Improved online management functionality.
  • Updated version numbers from 1.99.x to 2.x.y.

Advanced Message Handling

The addition of this functionality was inspired by a reply I got to an earlier post about bowerick. Thanks a lot to Evgeny (eaksenov) for the input. I hope that the new functionality is what you had in mind with your request.

Up to now, bowerick message producers and consumers only considered the actual payload. For sending, a producer only accepted a single argument, the data/payload to be transmitted. Analogously, the callback called by consumers on message reception only accepted a single argument, the received data/payload.

Advanced message handling now allows more sophisticated interaction when sending/receiving messages. Regarding the split between message producer and consumer, I consider the consumer part more complete by now. Thus, I will start the discussion with the consumer.


With the new advanced message handling functionality, a bowerick consumer can now also accept a callback with two arguments. If a two argument callback is passed, the first argument will contain the same data/payload as for the single argument callback. The second argument, is an instance of either the received message or the message headers, depending on which wire format/protocol is used.

For OpenWire, STOMP, and MQTT, the second callback argument is the received message instance. For STOMP via WebSockets (WS/STOMP), the second callback argument is the StompHeaders instance that was received along with the payload.

Please note: while the OpenWire and STOMP messages both implement javax.jms.Message, the concrete implementations are different, e.g., ActiveMQBytesMessage respectively StompJmsBytesMessage when transmitting byte array data. Furthermore, the messages received via MQTT (org.eclipse.paho.client.mqttv3.MqttMessage) do not implement javax.jms.Message.

Below is an excerpt as example of a two argument callback function:

(defn cb [data msg]
 (println "Received data:" data)
 (println "Message type:" (type msg)))
(def consumer (create-consumer broker-uri topic-name cb))


For producers, the advanced message handling is in a rather early stage. So far, only setting custom message properties for OpenWire and STOMP is supported.

In order to set message properties for OpenWire and STOMP messages, you have to pass a second argument to a producer instance in addition to the actual payload data. The additional argument is a map in which the message properties have to be associated to the :message-properties key. The message properties have to be defined as a map of string keys and arbitrary values.

The string keys are the identifiers used for naming the message properties. What type of property, e.g., Boolean, Int, Double, etc., is used is determined based on the type of the corresponding value.

Below an excerpt is shown as example:

(def prod (create-producer broker-uri topic-name))
(def msg-opts {:message-properties
 {"Some Boolean" true
 "Some Byte" (byte 42)
 "Some Double" 1.701
 "Some Float" (float 1.701)
 "Some Integer" (int 1701)
 "Some Long" 1701
 "Some Short" (short 1701)
 "Some String" "Enterprise"}})
(prod "my data" msg-opts)

Instead of hard-coding the identifier :message-properties, the var msg-prop-key from the bowerick.jms namespace can be used as key as well.

Please note that MQTT and WS/STOMP producers also support the second argument. However, the second argument will be simply ignored for now for these protocols.

Built-in Test Message/Event Producer

For testing, experiments, and demonstration purposes, it can be beneficial to have some continuous traffic flowing across the messaging system. Thus, I added a simple built-in message/event producer for synthetically generating and sending messages.

The new message/event producer generates message with 50 Hz. The messages contain x, y, and z coordinates of, say, a point. Currently, the z coordinate is constant and on the x/y plane the point follows a circular movement.

This message/event producer is the basis for a demo, which I will cover in a separate post later.

Improved Online Management Functionality

When running bowerick in daemon mode as broker, it provides some, currently very simple, management functionality. Previously, this functionality was implemented rather coarse such that it was not very user friendly and cumbersome to extent.

The new online management functionality is based on new embedded CLI functionality, which I recently added to cli4clj. For this post, I will just go with the summary that this will help to improve usability and extendibility of the online management functionality. I will write more about this cli4clj embedded CLI feature in a dedicated future post.

Updated Version Number

Since quite some time, I hade been using version numbers of 1.99.x. Originally, my intent for using the 1.99.x versions was that the release of the next major version, 2.x.y, was imminent.

I “just wanted to implement that one big change” and then switch to 2.x.y. Unfortunately, I never really got around to implementing that change and was distracted by other more urgent or fun aspects. Thus, I did not really make it to get rid of that 1.99.x version.

However, eventually, I got annoyed by this 1.99.x thing going on for so long. So, I finally decided to switch back to some more decent versioning and just do the jump to 2.x.y.

In future, I may need to do another major version bump when the “big change” finally comes. However, so far, I think it is much easier to have a reasonable version scheme rather than continually going on with this 1.99.x stop gap solution.


In this post, I announced the release of bowerick 2.1.0. Besides some technical details about new features etc. I also tried to provide some rationale for the new major version number.

In addition, I somewhat teased you with an outlook on some more future posts. So, I actually owe you at least two more posts, right now.

I hope you consider bowerick useful and am happy about your feedback and comments. As you could see in this post, sometimes, coming up with a feature request may actually lead pretty quickly to a corresponding implementation.

As usual, I am very happy about any constructive feedback.

Posted in Announcements, bowerick, Libs. | Tagged , , , , , | 2 Comments

bowerick 1.99.17 released.

In this post, I briefly announce the release of bowerick version 1.99.17. Compared to the next post I have planned, this is not the chronological but the, in my opinion, logical order.

Changes compared to the previous bowerick release are:

  • Enable heartbeat for Web Socket (WS) client connections.
  • Add simple examples for connecting to the broker from a web browser.

Having a heartbeat for WS client connections avoids disconnects due to timeout when using bowerick as WS client. The default values (10000 in ms) can be overridden by re-binding the *ws-client-ping-heartbeat* and *ws-client-pong-heartbeat* global dynamic variables.

In addition, I added two simple examples for using Message-oriented Middleware WS connections from a web browser. Playing with these examples actually was what motivated me to add the WS client heartbeat as the timeout disconnects became a little annoying over time. In the next post or posts, I plan to write about the WS web browser examples.

I hope bowerick is useful for you. I am happy about any constructive feedback and criticism.

Posted in bowerick, Libs. | Tagged , , , | 3 Comments

Video of My #clojuredconf / @clojuredconf Talk: “Packet Capturing with the JVM and Clojure – Yes, we can!”

The video was uploaded already quite some time ago. However, I still want to put a link on my blog to have all references in a common place.

In case you are interested, here is the teaser or abstract that I submitted for the conference schedule:

“In this talk, it will be shown that packet capturing with Clojure works fast, how it is made fast, and that Clojure offers amazing capabilities for processing such high-throughput stream data. Following a bottom-up approach, the covered topics include:

  • integration of low-level packet capturing with the JVM via JNI,
  • acceleration of packet capturing with the JVM up to the magnitude of 10 GBit/s speed,
  • a Domain Specific Language (DSL) for extracting information from raw binary data,
  • and a self-adaptive mechanism for automatically adjusting the data processing at run-time. While this talk focuses on packet capturing, the presented topics can also be applied to other application fields.”

The video is available from :clojureD via YouTube:

The slides of the talk can be found in an earlier post.

Once more, many many thanks to everyone involved in :clojureD: organizers, attendees, speakers, and everyone else. :clojureD was a fantastic experience as speaker, as attendee to the other talks, and as part of the many great conversations with the very nice people around.

Posted in Uncategorized | Leave a comment

test2junit Version 1.3.0 Released

As my last post about test2junit is some time ago, here is the very brief description: test2junit is a Leiningen plug-in that provides improved JUnit XML format output when executing clojure.test tests. In addition, it allows to automatically run the corresponding JUnit Report Ant task for generating HTML from the XML output. An example is available on the test2junit repository.

In this post, I announce the release of version 1.3.0 and briefly discuss the changes since the last announcement. The most relevant changes since the last announcement are:

With the fix to issue #10, the file and source code line at which a problem occurred are properly shown. It turned out that the culprit was just a wrong index. Thanks a lot to Andrew for spotting and reporting the issue!

System Properties of the JVM executing the tests are now included. Before just nothing was emitted for this part of the XML. An example for how this looks can be seen in the example output by scrolling to the bottom and clicking on “Properties”.

Furthermore, Stderr and Stdout are also included in the XML output. An example for how this looks can be seen in the example output by scrolling to the bottom and clicking “System.err” or “System.out” respectively.

The content shown for “System.out” actually includes Stderr as well. The reason for this is that I think it would make reading the output more complicated when Stderr and Stdout are separated into two different outputs. It would be, e.g., more difficult to related messages from Stdout and Stderr to each other. The output for “System.err” only shows Stderr. This makes it easier to check for important output from Stderr.

One potential drawback of including Stderr and Stdout in the XML output is that the output has to be redirected for capturing it such that it is not printed in real-time in the console right now. To accommodate this, the output is printed after collecting it.

This has two consequences: instead of being printed in “real-time” the output is printed in batches after the capture of one unit of output was done. In addition, Stderr and Stdout are both printed to Stdout. However, so far, I did not encounter negative effects of this in practice yet.

I hope that you consider the changes useful. In case you have comments, requests, or other feedback, it would be great if you send me your feedback.

Posted in Announcements, Libs., test2junit | Tagged , , | Leave a comment

clj-net-pcap Version 1.7.1 Released

I actually uploaded clj-net-pcap version 1.7.1 quite some time ago. Unfortunately, I was very busy and couldn’t even write an announcement. In this post, I briefly announce the clj-net-pcap version 1.7.1 release.

I did the work on clj-net-pcap version 1.7.1 in preparation for the :clojureD conference. The most relevant changes for version 1.7.1 are:

  • Use latest cli4clj version.
  • Add stderr-forwarder-fn.

My motivation for these changes was to provide a better live demo of clj-net-pcap. With the latest cli4clj version, the interactive command line interface (CLI) offers more convenient functionality.

With the stderr-forwarder-fn, the output printed for each packet is printed to stderr instead of stdout. By redirecting stderr to a named pipe or file, it is now possible to use the interactive CLI without the CLI being flooded with the packet output. This, in my opinion, eases the use of clj-net-pcap for simple experiments or demonstrations a lot.

Below, a screenshot of a demo setup is shown. On the top left, the clj-net-pcap interactive CLI is shown. On the top right, another shell is shown that was used to generate traffic via the ping command. On the bottom, the output from the named pipe to which the stderr output was redirected is shown.

The following listing shows how the named pipe is created and the new stderr forwarder is used to redirect the packet capture output to it:

mkfifo stderr-pipe
java -jar clj-net-pcap-1.7.1-standalone.jar -F stderr-forwarder-fn 2> stderr-pipe

The remainder of the example as shown in the screenshot above is simple to print what is written to the pipe via “cat” and to generate the traffic via “ping”.

I hope that this will be as useful for you as it was for me. Comments etc. are, as usual, highly appreciated. Thanks.

Posted in Announcements, clj-net-pcap | Tagged , , , | 2 Comments

Slides of my :clojureD Talk #clojuredconf

I uploaded the slides for my :clojureD talk:

Packet Capturing with the JVM and Clojure – Yes, we can!

Huge thanks to the organizers, speakers, attendees, and everyone else involved in :clojureD! 🙂

Posted in Uncategorized | 1 Comment