Keeping Confidential Information Out Of Git

I’ve launched yet another open source project on GitHub a couple of months ago and now it’s time to use it in production. For that, I had to put some confidential information in a file that is currently tracked by Git. That was the database connection credentials that I keep in a property file. Obviously, I couldn’t push that file to GitHub and I did’t want to keep that file in my staging area forever, but I still wanted to keep the file in the repository, so people could use it to configure their own development/production databases as well.

The file I’m talking about is usi4biz/resources/db-config.edn. Notice that I’ve put pretty dumb credential information there just to make it work in my development environment. This file doesn’t exist anymore in the master branch. I had to do a little tweak, inspired by WordPress, to address the issue.

Before adding any confidential info, I renamed the file to db-config-example.edn:

$ git mv resources/db-config.edn resources/db-config-example.edn
$ git add resources/db-config-example.edn
$ git commit -m "Renamed the database configuration file"

Then, I copied the file and named it after the original name:

$ cp resources/db-config-example.edn resources/db-config.edn

I edited the new file and added the production credentials. Now, I just have to ask Git to ignore it:

$ echo -e "resources/db-config.edn\n" >> .gitignore

This way, db-config.edn will be always out of my staging area whenever I change it. I just have to remember that if I ever need to add a new property I have to do it in both files. For the moment, I just explained in the README file that those wiling to use the application have to copy the file db-config-example.edn with the name db-config.edn because the code refers the file db-config.edn.

Installing Leiningen on Mac OS


I’ve been playing with Clojure for quite sometime now. It’s a functional language hosted on the JVM, with a growing community and a very rich ecosystem. You can find libraries for every major problem, but in case you cannot find, you can count on the interoperability with Java will bridge the gap.

Nowadays, every programming language and platform offer a development environment with a build tool as foundation. Take as example Maven, Gradle and Sbt. It isn’t different in the Clojure world. It uses Leiningen as a build and project management tool. So, I would like to share with you how I’ve managed to install and configure Leiningen on my Mac.

First, create the directory /Applications/clojure to store Clojure’s related tools:

$ sudo mkdir /Applications/clojure

Navigate to the new directory, download the Leiningen script and give to the downloaded file permission to execute:

$ cd /Applications/clojure
$ sudo curl -O
$ sudo chmod +x lein

Add the new directory to the $PATH to be able to execute it everywhere in your system. To do that, navigate to the directory /etc/paths.d and use vi to create a file named clojure.lein with the content /Applications/clojure:

$ cd /etc/paths.d/
$ sudo vi clojure.lein

This change is not immediately taken into account. So, you will have to close the current terminal and open a new on. Execute the following command to check whether the $PATH variable was correctly modified to include Leiningen’s path:

echo $PATH

You should be able to find the path /Applications/clojure concatenated within the value.

Finally, execute the command lein for the first time to install Leiningen:

$ lein

It will download the latest version of Leiningen and make you ready to program in Clojure. Start the Clojure REPL with the following command:

$ lein repl

Have fun with Clojure and Leiningen!

Working With JMS on JBoss Web Profile

If you didn’t get in contact with messaging systems yet you better do it soon. This concept is a key element in the architecture of scalable applications. Before it was a product but now it’s pervasive even natively embedded in some programming languages.

Let me help you to use messaging in a JavaEE application server. The Java application code is portable between application servers. Unfortunately, each application server has its own way to configure a messaging system. Since I can’t cover all of them, I will concentrate on JBoss 7 or superior (JavaEE 6/7). JBoss uses a messaging system called HornetQ, an open source message-oriented middleware. It offers queues (point-to-point) and topics (publisher-subscriber). I’m covering only queues in this post. Queues and topics can be used within a JavaEE application or across several applications. It’s a kind of integration pattern, but sadly less popular than web services. Since I’m not dealing with integration, I will narrow even more this post to cover a queue accessible locally only.


I recently had to use a queue to asynchronously generate large files. Users were waiting too much for a response from the server after requesting those large files. The problem became serious when multiple users were doing that request simultaneously. By using a queue, I was able to generate files asynchronously, so the users didn’t have to wait anymore, and in sequence, avoiding exponential use of memory and IO.

To put some pepper on the issue, we were using JBoss Web Profile and it doesn’t support messaging. We would need to migrate to JBoss Full Profile, but it would require us to migrate all development machines and all server environments, otherwise the deployment descriptor with the queue configuration would break the deployment everywhere. Also, migrating to the full profile would bring together several additional services – that we don’t need at all – just to consume more resources. So, I had to figure out how to make the messaging system work in the web profile.

The first idea that came to my mind was to simply identify the messaging configuration in the full profile (standalone-full.xml) and copy it to the web profile (standalone.xml). I started by adding the extension module:

<extension module=""/>

and with it comes its respective rather long subsystem:

<subsystem xmlns="urn:jboss:domain:messaging:1.4">
      <netty-connector name="netty" socket-binding="messaging"/>
      <netty-connector name="netty-throughput" 
        <param key="batch-delay" value="50"/>
      <in-vm-connector name="in-vm" server-id="0"/>
      <netty-acceptor name="netty" socket-binding="messaging"/>
      <netty-acceptor name="netty-throughput"
        <param key="batch-delay" value="50"/>
        <param key="direct-deliver" value="false"/>
      <in-vm-acceptor name="in-vm" server-id="0"/>
      <security-setting match="#">
        <permission type="send" roles="guest"/>
        <permission type="consume" roles="guest"/>
        <permission type="createNonDurableQueue" roles="guest"/>
        <permission type="deleteNonDurableQueue" roles="guest"/>
      <address-setting match="#">
      <connection-factory name="InVmConnectionFactory">
          <connector-ref connector-name="in-vm"/>
          <entry name="java:/ConnectionFactory"/>
      <connection-factory name="RemoteConnectionFactory">
          <connector-ref connector-name="netty"/>
          <entry name="java:jboss/exported/jms/RemoteConnectionFactory"/>
      <pooled-connection-factory name="hornetq-ra">
        <transaction mode="xa"/>
          <connector-ref connector-name="in-vm"/>
          <entry name="java:/JmsXA"/>
      <jms-queue name="ExpiryQueue">
        <entry name="java:/jms/queue/ExpiryQueue"/>
      <jms-queue name="DLQ">
        <entry name="java:/jms/queue/DLQ"/>

No changes from the original. I just copied and pasted the entire messaging subsystem. Then I added a socket binding just in case I needed queues and topics for integration purposes later on:

  <socket-binding name="messaging" port="5445"/>
  <socket-binding name="messaging-group"
  <socket-binding name="messaging-throughput" port="5455"/>

Finally, I added a reference to the resource adapter, defined above, in the EJB subsystem, as follows:

<subsystem xmlns="urn:jboss:domain:ejb3:1.4">
    <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>

And it worked! Be aware you can simply use the full profile to make the messaging work. No need to do all this configuration. But keep in mind that the full profile is going to load additional things you don’t need at all, such as:

  • container-managed persistence, deprecated in favour of JPA.
  • an implementation of CORBA.
  • abstracts manageable aspects of the J2EE architecture to provide a model for implementing instrumentation and information access.


On the application side I did three things:

1 – add the deployment descriptor hornetq-jms.xml to the folder WEB-INF to automatically create a queue during the deployment process. The descriptor has the following content:

<?xml version="1.0" encoding="UTF-8"?>
<messaging-deployment xmlns="urn:jboss:messaging-deployment:1.0">
      <jms-queue name="FileGenerationQueue">
        <entry name="/queue/FileGeneration"/>

2 – create a MDB (Message-Driven Bean) to listen to the queue and process the messages as they arrive. For example:

@MessageDriven(name="FileGenerationQueue", activationConfig = {
     @ActivationConfigProperty(propertyName = "destination",
                               propertyValue = "queue/FileGeneration"),
     @ActivationConfigProperty(propertyName = "destinationType",
                               propertyValue = "javax.jms.Queue"),
     @ActivationConfigProperty(propertyName = "acknowledgeMode",
                               propertyValue = "Auto-acknowledge")})
public class LargeFileGenerationBean implements javax.jms.MessageListener {
  public void onMessage(Message message) {
    // Code that will process messages coming from the queue.

3 – and modify a Request Scoped Managed Bean to send messages to the queue. For example:

public class MyManagedBean implements Serializable {

  private ConnectionFactory connectionFactory;

  private Queue queue;

  // Serializable class encapsulating data criteria.
  private DataCriteria dc;

  public String sendMessageToQueue(String message) {
    try (Connection connection = connectionFactory.createConnection()) {
      Session session = conn.createSession(false,
      MessageProducer producer = session.createProducer(queue);

      ObjectMessage message = session.createObjectMessage(dc);
    } catch (JMSException e) {

Let me know if you have any issues, then we can find the solution and make it better.

TomEE-CLI: An Alternative To Manage TomEE

About a year ago, when I was looking for alternatives to replace our Glassfish servers (why?), I had the chance to evaluate TomEE. Talking to TomEE’s team was indeed a pleasant experience. By far, the best support you can get from a JavaEE player. Just to give you an idea, they replied all questions in less than 24 hours, while we had to wait over a month to get the first feedback from RedHat about JBoss EAP. We had multiple evaluation criteria and, unfortunately, TomEE didn’t go well in the management part. JBoss offered redundant ways to manage the server, including a web API, a command line tool and a web console. Since the infrastructure team put too much weight on the management aspect, I had to agree and formally recommend JBoss EAP. Sometimes, we have to make unpleasant decisions, but that’s business.

As an open source enthusiast, I knew I needed to do something to help TomEE. So, I thought about contributing to the documentation but I had to step back because my daughter had just been born at the time. Looking at my GitHub profile, one can see how much of my free time was filled up with paternity love. The good news is she is growing fast and becoming less demanding, leaving some room for my open source projects.


In January this year, when my brain left hemisphere was in good shape again, I decided to learn Clojure, a functional programming language on the JVM. I’ve got so excited that I started telling my friends about what I would describe as a “mind-blowing experience”. One of them, Daniel Cunha, was particularly excited about that. We were talking all the time about infinity possibilities we have at hands with Clojure. Then he suddenly came out with a project proposal I couldn’t refuse: “Let’s write a client tool for TomEE. I’m trying to write one in Java, but it’s taking too long. Let’s write it in Clojure”. And then I said “Yesss! Of course”. Daniel didn’t realise but he was giving me the chance I was looking for: solving exactly the point where TomEE didn’t do well in our analysis. I’m sure Daniel didn’t expect such enthusiasm coming from a contributor.

On April 13th 2015 we released the first version of TomEE-CLI. We started our endeavour in Mars 9th and we managed to develop 11 functionalities within a month with just 300 lines of code. No doubt Clojure and its ecosystem has made it possible. Can you imagine what we can achieve within a whole year?!

How It Works

We basically developed a Clojure API to manage TomEE instances. This API is so simple that you don’t even need to learn Clojure to use it. Clojure’s syntax to call functions is remarkably obvious. If you aren’t familiar with LISP dialects you will probably ignore the fact that you’re actually coding valid LISPs expressions to manage your server. You may ask your self: “But, it’s an API so I need to write my own Clojure code to use it, right?”. Writing your own code is actually optional because you can use the REPL (Read-Eval-Print Loop) to execute Clojure expressions. In a single line of code you can call any of the functions available. Look how we use the REPL to invoke a function that installs TomEE 1.7.1 Plus in the working directory.


The REPL gives a real feeling of an interactive shell. That’s why we didn’t wait too long to release TomEE-CLI. It’s a basic, but valid user interface that people could start using immediately. Features like auto-complete, history and multi-line commands are also provided by the REPL. In the long run, the REPL won’t be the only way to interact with TomEE-CLI. We are planning to add a rich shell interface for experienced hackers, an in-line parameters interface for easy integration with automation tools such as Jenkins, and a web interface for beginners and remote administrators.

You can find installation instructions in the readme file and a complete list of functionalities in the project’s wiki.

You may be surprised I’m devoting time to a JavaEE initiative after leaving it behind. Well, software development is all about people. So, even when a specification sucks, people using it are still good people, thus I’m writing it for them. Besides that, I’m happy to write Clojure code to solve real world problems faced by JavaEE developers in a daily basis.

Daniel and I understand that we may not have many contributors because the actual Clojure source code looks weird for Java developers. That’s what I thought when I first looked at it. But I can tell you that I’m not that smart and I was able to grasp the language in less than a month. Now, I’m delivering new functionalities in a short period of time, preserving the same level of performance and robustness offered by the JVM. When I became a father I realized time is my most precious resource. I simply can’t waste it anymore.


What Comes Next

In my previous post I explained why I left JavaEE behind. Now, I’m going to explain my reasoning process to come up with what I’ll learn, teach and use next. The criteria I’m using are:

  • Cloud friendly: the technology should be ready to scale horizontally, without constraints, additional products or exponential use of resources.
  • Learning curve: I should be able to learn and teach fast even if it requires me to change the way I think about programming. I recognize I have lots of new concepts to learn before I realise the advantages of other technologies.
  • Performance: everything I write I want to be faster than any interpreted language. I know that premature optimization is a bad idea, but I need a technology that even when I decide to postpone optimizations it will be fast enough.
  • Community: the community doesn’t need to be big, but it should be active and kind with newcomers. The majority of libraries they produce should be open source.
  • Reusability: I should be able to reuse the libraries I’m used to, or find equivalent ones.
  • Coverage: I should be able to write the same kind of software I’m used to and not be limited if I decide to do more.
  • Documentation: the technology should be well documented, with books, websites, blogs, wikis and teaching materials.
  • Development Stack: the stack should implement MVC for web applications, database migration, database abstraction, SSL, authentication, authorization, REST web services, etc.

The fundamental choice starts with the programming language. It must support functional programming in order to be cloud friendly, but it also has to avoid mutable state to prevent concurrency issues and make it difficult for programmers to write code with side effects. I already use Java, but at this point we have to eliminate it because mutable state is the default behaviour in the language. To avoid it, we have to write a whole bunch of additional code that needs to be tested as everything else. Java requires the use of design patterns to overcome the deficiencies of the language. Static analysis tools, such as SonarQube, are required to keep the code safe, but, unfortunately, they require a significant effort that has nothing to do with the business problem we are solving.

“Most people talk about Java the language, and this may sound odd coming from me, but I could hardly care less. At the core of the Java ecosystem is the JVM.” James Gosling (2011, TheServerSide)

Despite the Java programming language being out of the picture, the Java Virtual Machine (JVM) is still relevant. It’s a portable and mature platform capable of running multiple programming languages in several operating systems with a transparent memory and thread management, with performance peaks compared to C/C++. What Java doesn’t do for us, other programming languages do, running in the same virtual machine and reusing the existing Java ecosystem, which is huge! Therefore, languages that have their own compilers and independent virtual machines are discarded because they hardly will reach the maturity and popularity of the JVM and the Common Language Runtime (CLR). So, at this point we discard Erlang, Harskell, Go, and all other languages that don’t run in the JVM or CLR.

I have mentioned CLR, the .net runtime, but I have no experience with it so far. So, I have to narrow my choices to JVM hosted languages. I couldn’t find any official  or reliable survey about the popularity of JVM languages, but I did find several pools showing that Groovy, Scala, Clojure and JRuby are indeed the top four JVM hosted languages, in no specific order.


Groovy‘s popularity is due to the fact that it looks very much like Java, but without its cumulative historical problems. Therefore, Groovy’s learning curve for Java developers is by far the lowest one compared to Scala and Clojure. Scala comes next with its richer type system and object orientation. We’re able to map our Java knowledge within Scala, but this language is so full of possibilities that it’s the hardest one to master. We have problems to read other people’s code because developers have too much freedom to express themselves. Clojure, on the other hand, is the hardest one to start programming because of its radical differences from Java, but it’s the easiest one to master because of its simplicity. We do a lot more with less code and the code is readable as long as you know functional programming principles. Since JRuby didn’t perform well in the surveys above, I’m discarding it for the moment.

The chart bellow shows job trends in the US, according to It actually reflects the size and influence of the community gravitating those languages. Groovy has been performing well since the beginning, but it is now threatened by Scala, although it isn’t clear yet which one will stand out. The interest for Clojure is constantly and shyly increasing, as functional programming becomes popular and the learning material available helps to reduce the introductory learning curve. In any case, it still has a long way to go.

Groovy, Scala and Clojure have at least the same coverage as Java, with the advantage of writing less to do more. There is absolutely no problem that can be solved only by using Java. Actually, concurrency problems are far more complex to solve with Java, making those alternatives much more interesting.

In order to master those programming languages, I had a look at the volume and quality of the documentation available. This is very hard to measure. For those who like numbers, I have compiled the following table:

Language Appeared Google StackOverflow
Groovy 2003 602K 11468
Scala 2003 1.510K 35207
Clojure 2007 350K 9278

The problem is that this table can be interpreted in many different ways:

  1. These numbers are far from precise. They change everyday because of the nature of the internet.
  2. Looking at the volume, we might conclude that the more entries we get the more documentation we can find, but it can also be a sign of complexity, taking a lot more documentation to explain a thing. Therefore, the fact that Clojure has less entries doesn’t mean it is less documented than Scala or Groove.
  3. Some languages are older than others, accumulating exposure to the community, thus producing more content. But in this case, older content are counted but hardly relevant nowadays.

I can say that the documentation I found was fairly good enough to address all my questions so far.

The last point is the development stack, a set of libraries and frameworks covering most of the needs of a regular enterprise developer. The following table shows a non-exhaustive list:

Feature Groovy Scala Clojure
Build Tool Gradle SBT Leiningen
Persistence Grails Slick HoneySQL
Database Migration Grails Play Framework Joplin
MVC Grails Play Framework
Compojure + Ring
Security Spring Security SecureSocial
Testing Spock Scala Test Expectations
IDE Support IntelliJ
RESTful Web Services Grails Spray
Play Framework

Notice that Grails appears several times in the Groovy column. It’s a web framework offering a good deal of productivity thanks to a Convention-over-Configuration approach. The same happens in the Scala column with several occurrences of Play Framework. While the approach followed by Groovy and Scala offers more productivity and reproducibility, it also reduces the flexibility of the architecture, making it hard to replace an inefficient part by a more efficient one. Clojure is more concerned about the architecture and offers a separate library for every feature. In case a competitor library becomes more efficient than the one we are using, we can easily integrate the new library and gradually replace the inefficient one.

My strategy to use those three technologies from now on is the following:

  • Groovy: when I find a chaotic and inefficient JavaEE application, I will propose to migrate it to Groovy + Grails. It will make the project economically viable again and recover the time wasted with complexity. The team can start writing Groovy code right away in the same project, gradually replacing the Java code and JavaEE dependencies.
  • Scala: the main advantage of the Scala stack is its reactive platform, offering an unprecedented performance boost for concurrent applications. So, when performance is one of the main requirements of the application and the team is smart and organized, I will suggest Scala as the way to go.
  • Clojure: For everything else I will suggest Clojure, which is very productive, simple and has an excellent performance. That’s by far the best programming experience I ever had.

In summary, I still use JavaEE for existing well designed applications, but I will use Groovy to save chaotic JavaEE applications from complete failure. Scala and Clojure will be used for new projects, depending on their characteristics and context of use.