Connecting to MongoLabs on heroku

For an internal Topicus application I wanted to deploy to Heroku and utilize MongoDB through MongoLabs. The main reason to use MongoLabs: they have a free 240MB database plan, and I wanted to try MongoDB to see how it would work.

Getting it to run on Heroku was kind of a challenge since I want to build a Java/Wicket application, and most documentation relies on Ruby deployments. In order to connect to MongoLabs you need to do the following:

MongoURI mongoURI = new MongoURI(System.getenv("MONGOLAB_URI"));
DB connectedDB = mongoURI.connectDB();
connectedDB.authenticate(mongoURI.getUsername(), mongoURI.getPassword());

What evaded me was that you need to explicitly authenticate using the provided username and password, otherwise you will get authorization errors. The documentation didn’t show this as a required step unfortunately.

Of course you should check if authentication succeeded, and that no error occurred.

EHCache and Quartz phone home during startup

One might call EHCache (the Java caching library everybody loves) ET-Cache, since it keeps phoning home during startup. While probably just implemented as a usability feature, I find it quite nefarious, especially since Quartz (the job queuing library everybody loves) does *exactly* the same.

The culprit lies in net.sf.ehcache.util.UpdateChecker and org.quartz.util.UpdateChecker.

Information sent to Terracotta HQ include:

  • a client ID taken from your local IP
  • os.name
  • java.vm.name
  • java.version
  • os.arch
  • QuartzVersion
  • EhCache version
  • something about source
  • uptime-secs
  • patch level from Quartz/EhCache

Needless to say, this is something that should not be enabled by default, and only with a big opt-in questionnaire… This also sparks the question if the cache doesn’t send *more* information home than just the update information? It is after all a product designed to send information across the network—what is one extra node more in the grand scheme of things? Has anybody audited the code for nefarious code?

In any case: to disable phoning home everybody should start their applications with the following command line parameters:

  • -Dnet.sf.ehcache.skipUpdateCheck=true
  • -Dorg.terracotta.quartz.skipUpdateCheck=true

Or you can configure it in your ehcache.xml according to the user manual. Quartz is similarly configurable in the quartz.properties.

According to Alex Miller, a former Terracotta employee, it is not evil and a price we need to pay to use open source software.

I disagree strongly: this undermines the premise of trustworthy open source. The download page doesn’t mention the phoning home, neither does the announcement of ehcache 2.2 (last july), it is summarily mentioned in the configuration part of the manual, which you typically don’t read when you just upgrade your dependency to the latest version and see that everything still works as usual. The same goes for Quartz: it was apparently added in quartz 1.7.3, but no mention of this in the release notes. Neither of the possibility to disable phoning home which was added in quartz 1.8.

In my opinion, this is unacceptable behavior for any open source product, which severely undermines the trust we spent building in the last couple of years making open source a viable alternative to closed software.

SHAME ON YOU TERRACOTTA!

Oracle tells JCP EC to fuck off and bow to its will

In the published minutes of the JCP EC meeting in Bonn last October, the complete (might I say epic) failure of Oracle’s Java Community stewardship becomes visible (emphasis mine):

Doug asked Oracle to acknowledge that it was asking the ECs to condone breaking the JSPA rules. He said that if he was put in a position where he had to condone breaking the rules he would have to resign. Ken said that he understood, and would regret it if Doug resigned, but pointed out the importance of allowing the conversation to go forward.

Doug Lea resigned from the JCP EC on 22 October 2010.

How is that for being positive and constructive?

Atlassian Ultimate Wallboard competition comes to an end

Last month we submitted an internal project at Topicus into an international competition hosted by Atlassian concerning so called Wallboards. Wallboards are (agile) information radiators which show stuff like build status, sprint planning and other interesting metrics. While we didn’t win the competition (congratulations Vodafone Web Team!), we are glad to have participated in this competition!

Our board was heavily inspired by the Panic Status Board, and we took their premise and went a bit overboard. Our dashboard (dubbed “Topicus Board”) shows our project status: production server status, average request times, number of concurrent users, requests per minute, Hudson build status, number of unit tests, server uptime, deployed application versions, a list of servers with status indication (up/down), etc. Added to that we show departure times of trains of our local train station (the Topicus offices are next to the Deventer central station), SVN commits and mantis issues, Google calendar events and the local weather.

We built our board with Java using Apache Wicket (raise your hand if you thought we’d use something else ;-) , jquery (wiquery), CSS3 and HTML5. The board animates the living daylights out of our Dell workstation (Intel embedded graphics and Linux drivers don’t work too great). The code is open source (GPL) and available from https://github.com/dashorst/dashboard.

When we started with the project Atlassian hosted a contest for the ultimate wallboard, so we figured to enter the competition, and get ourselves a nice deadline. The competition closed November 24th. And today the results finally came in. Unfortunately our wallboard didn’t take the grand prize for being the ultimate wallboard, but we did manage to get a honorable mention:

This wallboard also boasts a very clean and simple design with sexy animations. Products stats, builds and issue details are complimented by local railway schedules, twitter, weather, and google calendars — including birthdays and beer time!

Judge Dick Wall added:

Features like tracking transport delays, the excellent two speed ticker at the bottom, and the polish of the CSS animations all stand out in this demo.

We thank Atlassian for hosting this competition and hope they’ll host one next year.

Downloading the internet with Maven in a new light

I have my share of complaints like everybody else about Apache Maven and one of them is that upon installation (or upgrading to a new plugin version) it starts downloading half of the available internet. Maven is constructed in a highly modular fashion, requiring lots of different, small, focused Java libraries. I’d like the distribution to contain those libraries, but I digress. Tonight I saw that not only Maven is structured this way. It is something *all* open source projects got.

For example, the much touted Ruby on Rails project with their disdain for everything Java would probably cringe at Maven (it uses XML after all). But installing Ruby on Rails and for example Radiant CMS with some plugins is a futile attempt in finding the right invocations of: script/*, rake, gem, port and other commandline tools you’ll want to get familiar with. All these tools start downloading stuff from the internet from different repositories (SVN, ruby forge, etc).

Maven: you’re not alone anymore in downloading the internet for your builds…