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.

• Download and install the javadeveloper_for_mac_os_x_10.6__10m3425.dmg from developer.apple.com (free registration required)
• Install the client update (comes from the automatic update functionality in OS X), it doesn’t matter in which order you do these two steps)

Next run the following commands in a terminal:

cd /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
sudo ln -s /Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home/src.jar
sudo ln -s /Library/Java/JavaVirtualMachines/1.6.0_26-b03-384.jdk/Contents/Home/docs.jar

Eclipse will now be able to find the sources for the Java classes.

If you have problems finding the OS X Java developer downloads:

• Go to: Resources
• Click on “developer downloads”
• Click on “Java” in the right side menu

Apple made it impossible to provide a direct link, so you’ll have to navigate the developer website yourself.

(updated with navigation to Java downloads)

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!

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?

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.