SWTError: No more handles [gtk_init_check() failed] running platform tests (on Linux)

When running platform tests on Linux (and Mac?) one might encounter the following exception:

org.eclipse.swt.SWTError: No more handles [gtk_init_check() failed]
at org.eclipse.swt.SWT.error(SWT.java:4445)
at org.eclipse.swt.widgets.Display.createDisplay(Display.java:929)
at org.eclipse.swt.widgets.Display.create(Display.java:913)
at org.eclipse.swt.graphics.Device.<init>(Device.java:157)
at org.eclipse.swt.widgets.Display.<init>(Display.java:509)
at org.eclipse.swt.widgets.Display.<init>(Display.java:500)
at org.eclipse.swt.widgets.Display.getDefault(Display.java:1719)
at org.eclipse.e4.ui.tests.workbench.InjectionThreadDomainTest.setUp(InjectionThreadDomainTest.java:84)
at junit.framework.TestCase.runBare(TestCase.java:139)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:129)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at junit.framework.TestSuite.runTest(TestSuite.java:255)
at junit.framework.TestSuite.run(TestSuite.java:250)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:459)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:675)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:382)
at org.eclipse.pde.internal.junit.runtime.RemotePluginTestRunner.main(RemotePluginTestRunner.java:62)
at org.eclipse.pde.internal.junit.runtime.CoreTestApplication.run(CoreTestApplication.java:23)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:109)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:80)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:372)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:226)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:636)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:591)
at org.eclipse.equinox.launcher.Main.run(Main.java:1450)
at org.eclipse.equinox.launcher.Main.main(Main.java:1426)

The underlying cause isn’t found in SWT though, but in the .launch configuration’s environment setting. In order to run the tests on a dedicated DISPLAY to avoid interferences, tests set the DISPLAY env var explicitly. Thus, an X instance has to be made available. This is easily done by installing Xvfb the X virtual frame buffer (e.g. “sudo apt-get install xvfb”) and starting it on 1:0 with “Xvfb :1 &”. Voilà, this magically increases the number of handles. ;-)

Launch config Environment Tab Eclipse with Display

Apache Felix HTTP whiteboard pattern on Equinox

Unless I am missing something obvious, using the Equinox HttpService requires one to:
  • a) get the HttpService from the OSGi service registry
  • b) register the HttpServlet on the HttpService via a call to registerServlet(..)
This can be done however much more elegantly and – way more importantly – in a dynamic aware fashion meaning, that the HttpServlet that is registered survives life-cycle changes of the HttpService.
E.g. consider the case where one registers the HttpServlet with registerServlet(..) and the HttpService is redeployed afterwards. Unless the HttpService maintains its internal state (which is rather unlikely if e.g. Tomcat gets replaced with Jetty), the HttpServlet won’t be available anymore and consumer code will have to re-register the HttpServlet again (by listening to life-cycle changes of the HttpService).
If, on the other hand the HttpServlet is simply registered with the OSGi service registry as a javax.servlet.Servlet μService (SR never goes away), the HttpService itself (or an extender as a matter of fact) can lookup all services of the javax.servlet.Servlet type whenever its need to (read when the HttpService transitions through life-cycle changes).
To leverage this on Equinox, just follow the steps below:
  1. Download recent versions of both bundles ‘HTTP Service API’ and ‘HTTP Service Whiteboard’ to e.g. Eclipse’s dropins/ folder
    1. It is version 2.2.2 as of writing
  2. Add also bundle org.eclipse.equinox.http.jetty and its dependencies to the launch configuration
    1. Alternatively use Felix’s incarnation of Jetty called ‘HTTP Service Jetty’
  3. package org.kuppe.exmpl;
    import java.io.IOException;
    import javax.servlet.ServletException;
    import javax.servlet.http.HttpServlet;
    import javax.servlet.http.HttpServletRequest;
    import javax.servlet.http.HttpServletResponse;
    public class ChatServlet extends HttpServlet {
        protected void doGet(HttpServletRequest req, 
                             HttpServletResponse resp)
                throws ServletException, IOException {
  4. <?xml version="1.0" encoding="UTF-8"?>
          <provide interface="javax.servlet.Servlet"/>
        <property name="alias" type="String" value="/chat"/>
  5. Set ‘Bundle-ActivationPolicy: lazy’ and list the component xml as a Service-Component for the DS extender in the MANIFEST.MF
    1. Do not forget to explicitly add DS org.eclipse.equinox.ds to your launch until capabilites are available
  6. Optionally add -Dorg.eclipse.equinox.http.jetty.http.port=8181 to change the Jetty port to 8181

Real word scale greenhouse (temperature)

On my route to rebuild the M2M demo at real-world scale, I have taken the first step. An old (from around 2004) and absurdly underpowered ARM Intel XScale IXP420 running today’s Debian Wheezy (NSLU2) with just 266mhz has been recommissioned to act as a temperature sensor (why buy an Rasperry Pi or Arduino, if you can recycle?). The actual thermostat is a cheapish ~10bucks USB connected “TEMPer” device.



Once the hardware is wired up and put in place, the following instructions build the pcsensor binary that is needed to read data from the USB dongle:

# Install Debian necessities
apt-get install libusb-dev build-essential

# Get source (without git installed, download zip file from github)
# (I had to hack the original code to continuously flush the output to stdout to subsequently read it with mosquitto)
git clone https://github.com/lemmy/usb-thermometer.git

# Build binary
cd usb-thermometer/

# "Install" into system
cp 99-tempsensor.rules /etc/udev/rules.d/
cp pcsensor /usr/local/bin/

At this point a simple monitoring tool like e.g. munin can already show the temperature readings for last night – classico.


Rendering to a static web page however is too old school and thus I wanted each reading to be send out with MQTT so that I can get the readings on any smartphone (or browser in realtime below). Fortunately, Wheezy comes with a simple MQTT command line client that is easily connected to the pcsensor process (Btw. re-spawning a new pcsensor process for every reading and piping the output to mosquitoo turned out to cause problems on the USB layer (device re-connects). The current solution with long-lived processes is also less resource intensive):

# Start a pcsensor process and send its output via mosquitto (line by line) to m2m.eclipse.org
pcsensor -c -s -l | mosquitto_pub -t 8742hvvgsdf/temp -l -h m2m.eclipse.org

Thanks to mosquitto’s javascript client (though deprecated in favor of Paho) and websockets it is actually almost trivial to show MQTT messages in-line in a blog post like this one. :-) (I will leave it to the educated reader to lookup the source code manually. It’s almost identical to their examples)

Current temperature reading is -1 in °C for topic NA
(with timestamp epoch)

Btw. this project serves a real world purpose too ;-). The greenhouse has electrical heating to protect the plants from frost over winter. Last winter though, the heating broke and all plants died as a consequence. Thus, the temperature readings are written to a local (history) file and collected by said Munin. Munin then sends out alarms via email when a certain threshold gets reached:

# Optionally one can multiplex the sensor reading to a local file to feed the data also to munin:

# Create ramdisk to avoid writes to the slow and worn out USB pen drive
mkdir /var/lib/ram; chmod 777 /var/lib/ram
mount -t tmpfs -o size=256 tmpfs /var/lib/ram

# Or permanently
echo 'none /var/lib/ram tmpfs nodev,nosuid,noexec,nodiratime,size=256 0 0' >> /etc/fstab

# Write a local history to a tiny (ramdisk) file
pcsensor -c -s -l | awk '{print; print >f;close(f)}' f=/var/lib/ram/temp.txt | mosquitto_pub -t 8742hvvgsdf/temp -l -h m2m.eclipse.org

# Save the following file
echo '#!/bin/sh
case $1 in
cat < <'EOM'
graph_title Temperature
graph_vlabel temp in C
graph_args --base 1000 -l 0
graph_category Temperature
temp.label Temperature
temp.warning 0
temp.critical -5
exit 0;;
temp=`cat /var/lib/ram/temp.txt | tail -1`
echo "temp.value "$temp""' > /etc/munin/plugins/temperature

To automatically start temperature readins at boot time, create (yet another) script and have it spawned by init.

echo '#!/bin/bash

# make sure pcsensor, awk and mosquitto are killed along with this script
# http://riccomini.name/posts/linux/2012-09-25-kill-subprocesses-linux-bash/
trap 'kill $(jobs -p)' EXIT

# do the actual work
/usr/local/bin/pcsensor -c -s -l | awk \'{print; print >f;close(f)}\' f=/var/lib/ram/temp.txt | /usr/bin/mosquitto_pub -t 8742hvvgsdf/temp -l -h m2m.eclipse.org
' > /usr/local/bin/measureTemp.sh

sudo echo '# measureTemp
mt:2345:respawn:/usr/bin/sudo -u markus "/usr/local/bin/measureTemp.sh"' >> /etc/inittab

Quick’n'dirty twitter2xmbc hack to show #tatort related tweets on Sunday night

# Get recent version of ttytter (old versions fail to auth)
wget http://www.floodgap.com/software/ttytter/ttytter.txt -O /usr/local/bin/ttytter && chmod +x /usr/local/bin/ttytter


# Get list of search result
TWEET=`ttytter -runcommand="/search #tatort"| tail -1 | python -c 'import json,sys; print json.dumps(sys.stdin.read())'`

# Prepare json request
echo "{\"id\":1,\"jsonrpc\":\"2.0\",\"method\":\"GUI.ShowNotification\",\"params\":{\"title\":\"Tatort\",\"displaytime\":20000,\"message\":TWEET}}" | sed 's/TWEET/'"$TWEET"'/g' > /tmp/tmp.json

# Send request
curl -u xbmc:xbmc -H "Accept: application/json" -H "Content-type: application/json" -X POST --data @/tmp/tmp.json http://localhost:8080/jsonrpc

Btw. it is trivial to read the currently playing title from xbmc via curl as well to adapt to whatever one watches.

Save the date – Hamburg Eclipse /ˈhakəθɒn/ – November 22. 2013

As a sequel to the very successful ECE hackathon last week, we are going to run another hackathon in Hamburg (see wiki for more info) in ~two week from now. So save the date, spread the word and help us put eventually more dots on the Eclipse Committer world map.


My newest server ready to be shipped to the datacenter


Programatically push configuration into OSGi ConfigurationAdmin

Yesterday I lost half an hour when I struggled to push a configuration into OSGi ConfigurationAdmin. The org.osgi.service.cm.ManagedService was in fact called, but the Dictionary of properties was always null. It turns out, I forgot that one has to lookup the org.osgi.service.cm.Configuration not just by service PID, but also by (bundle) location. And since the location was not matching, the configuration was not a valid config for the bundle that implements the ManagedService.
Below is how one correctly configures the ManagedService registered with PID “my.ManagedService.Service.Pid” (service.pid). Notice the “?” location wildcard!
String servicePID = "my.ManagedService.Service.Pid";
Configuration configuration = 
	cm.getConfiguration(servicePID, "?");
Dictionary<String, Object> properties = 
if (properties == null) {
	properties = new Hashtable<String, Object>();
properties.put("someKey", "someValue");

Speaking at EclipseCon Europe 2013

I am going to co-present two talks at this year’s EclipseCon Europe in Ludwigsburg in October. The first talk is titled “Discover Remote OSGi Services” and Wim and I will show the latest and greatest of ECF‘s implementation of OSGi remote services.

The current state of Service Oriented Architecture (SOA) is intimidating. The set of standards invented to “make your life easier” has been growing like wildfire: xml, soap, wadl, widl, wsdl, rest, bics, wxscm, sscm, web.xml, ramp, etcetera etcetera.

On top of these protocols you can use a wealth of tooling and frameworks to such an extend that even you, the tech, don’t know what is going on…

Sometimes you wish that remote services were simple. Just implement an API, expose this API as a service in your OSGi runtime and let network clients use this implementation. If you could only focus on the meat and not on the infrastructure then you could be on your way to solve your business problems instead of solving configurations.

This talk explains how the ECF project will take your existing OSGi service and promote it to a network service. The network service will be peer to peer or it will be registered with a discovery server and advertised to any interested clients. The clients then can use the service as if it was a local service. ECF has implemented the new OSGi RSA specification in order to achieve this.

ECF committers Markus Kuppe and Wim Jongman will entertrain you on this remote services discovery tour which will include live coding. We will demonstrate how to promote an OSGi service to a remote service. Together we will build a simple remote service and see how all the remote services will be consumed by our client.


Become a Eclipse Committer in 20 min and fork the Eclipse IDE” with Lars shows how easy and straightforward contributing to Eclipse actually can be. This talk will focus less on the process but dive into the technical aspects working with ‘org.eclipse’ code instead. Even if you are a (downstream) consumer of Eclipse code you should attend the talk though. What I learned throughout various consultancy gigs is that you want to be able to fix bugs in Eclipse code rather than clumsily work around it. Here’s the excerpt:

The Eclipse SDK is available via Git and the common build infrastructure allows to build your own Eclipse IDE. Join this talk to learn how you can checkout the Eclipse IDE source code, modify it, commit your changes and build the Eclipse SDK using CBI and Maven / Tycho.

If you follow the approach described in this talk can learn how to build your own Eclipse IDE flavor to test your own developments before contributing them back to Eclipse.

Unfortunately, the program committee decided that software verification does not really fit into the overall theme of the conference and rejected my talk on TLA+ named “From the Ivory Tower to Eclipse – Model checking made easy“. Well, maybe next time…

Sending events to e4 applications from outside of e4

e4 uses an event bus to let different pieces (e.g. parts) of an e4 application communicate. Architecturally, this leads to low coupling (doubleplusgood) due to the fact that the various pieces only need to know the event topics (String constants), which are ideally defined centrally in a common bundle. If you happen to never leave the e4 application realm you are lucky and can stop reading here.
For the rest of us though – who face the requirement to send e4 application events outside of e4 – the problem is that e4 does not use the org.osgi.service.event.EventAdmin directly. It comes with its own org.eclipse.e4.core.services.events.IEventBroker. This alone would not pose an unsolvable problem (one could simply get the IEventBroker instead of EventAdmin from OSGi), but IEventBroker does not get registered with the OSGi service registry (see bug #391097). Luckily for us, the e4 team – even though they decided against reusing the OSGi org.osgi.service.event.EventAdmin directly – implemented IEventBroker as a wrapper around EventAdmin. So in order to send an event to e4, one simply has to get/lookup the OSGi EventAdmin from the OSGi service register (either programmatically or with DS).

If one’s use case also requires sending a payload along with the event, the Dictionary/Map of org.osgi.service.event.Event has to contain the element under the special key org.eclipse.e4.core.services.events.IEventBroker.DATA.

Map<String, Object> map = new HashMap<String, Object>();
map.put(IEventBroker.DATA, payload); 				

Event event = new Event(MyE4EventConstants.TOPIC_SOME_TOPIC, map);

ServiceReference<EventAdmin> serviceReference = 
EventAdmin ea = context.getService(serviceReference);

LyX export to markdown

Command line (Lyx > Markdown)

lyx –export latex file.lyx
pandoc –no-wrap -f latex -t markdown file.tex > file.md

Command line (Markdown > Lyx)

pandoc –no-wrap -f markdown -t latex file.md > file.tex && tex2lyx
file.tex && lyx file.lyx

(–no-wrap makes sure we don’t screw up e.g. \hrefs by spanning them
over multiple lines)

sudo apt-get install pandoc lyx


pandoc –no-wrap -f latex -t markdown -o $$o $$i

(might need extra whitespace at end)