Selective push notifications available

September 21, 2018 04:00 AM

The connectivity service supercharged Ditto’s flexibility in integrating with other services. It’s such a great feature to let the other connected services know about thing updates and property changes. Even the direct exchange with real-world assets became more flexible through the multi-protocol support. But with a steady increase in connected devices, those messages easily sum up to a huge number.

Note: In order to simplify a little, we here use the term message as synonym for both Ditto signals and messages.

Also, not every consuming application needs to know everything that’s going on. In fact, the only use case that requires processing of every message is logging. Therefore most of the times an application waits for a specific message to trigger a specific action. So all other messages are discarded unused. This adds a lot of unnecessary overhead both to the message transport capabilities and the processing of messages at the receiving end.

But what if you could avoid receiving those messages at all.
Well, you can!
This is exactly what selective push notifications do: Configurable message filters that are applied to Ditto’s publishing connection before anything goes on the line. They can help you with a lot of problems in a bunch of scenarios:

  • Bandwidth limitations: The amount of occurring events is too large and/or frequent to be delivered via the available channels. With selective message filters, you can mute the noise in your event stream.
  • Information hiding: Let consuming services only know what they need to know. Message filters allow you to control all published content in great detail.
  • Specialized notifications: A specific event filter can be used to set a value thresholds or a status-change trigger. This removes the burden of implementing filter logic on the application side.
  • Event routing: Create multiple connections with Ditto’s connectivity service and route your events through those aligned with your requirements. All by specifying appropriate filters for your connection targets.

The following diagram visualizes this context:

visual comparison

With the upcoming Ditto release 0.8.0-M2, those filters are available for the following endpoints:

  • WebSocket
  • Server-Sent Events (SSE)
  • All supported connectivity protocols (AMQP 0.9.1, AMQP 1.0 / Eclipse Hono, MQTT)

You can use a basic namespace filter on the following topics:

  • Twin events
  • Live events
  • Live messages
  • Live commands

This filter is a comma-separated list of selected namespaces. It only allows messages related to one of the given namespaces.

Furthermore, there is an additional RQL filter for an advanced description of twin and live events. Powered by the mighty syntax of Ditto’s search API it allows configuring the selected events in the same manner as you search for things.

Check out the documentation for more information on options and configuration.

A simple example

Imagine you have a flat with multiple environmental sensors: Some measure temperature, some humidity and some both. This information can be useful for different applications. In our case, a smart thermostat uses the sensor data to control the indoor climate and there is also a fire alarm installed that detects fires by abnormal high measured temperatures

The following figure displays this setting:

example setup

So let’s start with the prerequisites. You need:

  • A running Ditto instance with a valid user (You can follow our Hello World example to create one). This example uses dittos default user on a locally running instance.
  • A tool for executing HTTP requests (e.g. Ditto’s Swagger API, cURL, Postman). We use this to create our twins and simulate the sensors.
  • A modern browser supporting WebSockets. This example uses as a websocket client. The site will tell you if your browser supports the WebSocket protocol. We will mock our applications this way.

The digital twins

First we configure our sensors digital twins:

A temperature sensor

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
       "features": {
         "environmentSensor": {
           "properties": { 
             "temperature": 0.0
     }' \

A humidity sensor

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
       "features": {
         "environmentSensor": {
           "properties": { 
             "humidity": 0
     }' \

A combined temperature and humidity sensor

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
       "features": {
         "environmentSensor": {
           "properties": {
             "temperature": 0.0,
             "humidity": 0
     }' \

And finally, a teapot

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
    '{}' \

Mocking the consuming applications

Open your browser on This site allows you to connect with any WebSocket endpoint and supports simple sending and receiving of messages. The interface is shown below: site

Enter Ditto’s WebSocket endpoint with user credentials ws://ditto:ditto@localhost:8080/ws/2 and hit the Connect button. The log output should confirm the action by printing a simple CONNECTED.

This means the socket is open and you’re able to receive messages from Ditto. But first, you should let Ditto know in what kind of messages you’re interested. This interest differs for both of the example applications:

The thermostat app only needs to know every humidity and temperature report so you can define a filter for change events on twins having those properties:


Paste it into the Message input and use the Send button to post it. Ditto should acknowledge with a START-SEND-EVENTS:ACK.

That’s it for our thermostat app, let’s proceed to the fire alarm. Open again in a separate tab and repeat the connection process. But instead of consuming all temperature and humidity reports, we only want to be notified when a specific temperature threshold is exceeded. 90°C seems to be a solid value for this:


After receiving Ditto’s acknowledgment, you’re done with the configuration.

Report mocked sensor values to Ditto

Use Ditto’s HTTP API to send mocked data on behalf of our sensors. First report a new humidity value for the humidity sensor:

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
    '55' \

Now check both tabs. The thermostat tab should have received an event with the reported value while nothing happened in the alarm tab.

Continue with some temperature data from another sensor:

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
    '23' \

The value change should be reported to the thermostat, but still no events for the alarm tab.

Finally it’s time to start a fire. Report a very high temperature for the third sensor:

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
    '120' \

Now both applications should have received the reported data, and the fire alarm can use this event to (virtually) trigger its bell.

But what about the teapot? Let him declare his identity by setting a personal message:

curl -X PUT -u 'ditto:ditto' --header 'Content-Type: application/json' -d \
       "properties": {
         "message": "I'\''m a teapot"
     }' \

Unfortunately, no one cares and this no one is notified about that change.

We do hope that you care about this feature, we think it’s really awesome.


The Eclipse Ditto team

September 21, 2018 04:00 AM

WTP 3.11 Released!

September 20, 2018 09:01 PM

The Eclise Web Tools Platform 3.11 has been released! Installation and update can be performed using the SimRel 2018-09 Update Site or through the Eclipse Marketplace. Release 3.11 is included in the 2018-09 Eclipse IDE for Java EE Developers and Eclipse IDE for JavaScript and Web Developers, with selected portions also included in other packages. Adopters can download the R3.11 build itself directly.

More news

September 20, 2018 09:01 PM

Xtext 2.15 released!

by Xtext-Team ( at September 20, 2018 01:00 PM

We are proud to announce Xtext and Xtend 2.15! As you can learn from the release notes (Xtext and Xtend), the focus of this release was on stability, quality and performance. Especially the Xtend Gradle build could be improved significantly and the integration with Eclipse 2018-09 works like a charm, now.

In the last three months, it turned out to be rather challenging to keep up with the new concept of rolling releases at Eclipse. We had to learn a lot and more than once we did this the hard way. In the end we are pretty satisfied with the outcome, though. And besides quite some fundamental groundwork on the process-side to get ready for the shorter 3 month release cadence, we did also find the time to squeeze in a few goodies that will make working with Xtext DSLs even more pleasant.

Bye bye Chunk 5 of 17

One of the noticeable adjustments, that we made, is the improved progress reporting. We redid the logic that tracks the remaining number of files during a build in Eclipse and are now issuing more fine grained feedback to the user. This was possible due to recent changes in the Eclipse platform. We do no longer face a performance degradation when reporting on such a granularity so it was about time to provide more insights on what's going on during a full build.


For the unit test addicted among us

Besides the fact that Xtext does now correctly mark test folders as such, when you create a new project, we are constantly working on improvements of the APIs for testing various Xtext services. This time, the infrastructure to test lexical and semantic coloring was added. It greatly simplifies testing of custom highlighting logic.


Also Xtend is now aware of the JUnit annotations and will flag methods with an invalid return type (read: non-void) already in the editor so you get immediate feedback if the type inference has computed some undesired return type for your test method. Especially when working with fluent test APIs this may be very handy.


There is more

The 2.15 release has more goodies that you can read about in the release notes of Xtext or Xtend. Being it the improved support for Task markers in Eclipse, the tweaks to the handling of files, that are external to your workspace, a command-line interface for creation of projects or new APIs in the core, make sure you do not miss some interesting bit or piece.

We value your feedback

As usual, if you face any issues with Xtext 2.15 or if you do have any other feedback, please don't hesitate to get in touch with us on GitHub, via the newsgroup or simply drop us a comment.

Contact the  itemis Xtext team

by Xtext-Team ( at September 20, 2018 01:00 PM

Null/Undefined Analysis in N4JS

by Project N4JS ( at September 20, 2018 12:39 PM

The N4JS IDE integrates validations and analyses that are quite common for IDEs of statically typed languages. However, these analyses are seldom available for dynamically typed languages like N4JS or TypeScript. In this post we present the null/undefined analysis for N4JS source code.

TypeError: Cannot read property of undefined
- Developer's staff of life

The runtime error above occurs pretty often for JavaScript programmers: A quick search on Google returned about 1.2 million for the term TypeError: Cannot read property of undefined. When constraining search results to the query will still yield 126 thousand results. These numbers are comparable to the somewhat similar error NullPointerException which has about 3 million hits on Google and about 525 thousand when constrained to Some of these results are caused by rather simple mistakes that a null/undefined analysis could detect. As a result, the developer could restructure his code and remove these potential errors even before he runs his first test and hence save time.

Null/Undefined Analysis

The N4JS IDE provides static analyses to indicate problems when it detects a property access on a variable which can be null or undefined. The analysis considers all assignments that occur either through a simple assignment expression or via destructuring. Loops, conditional expressions (e.g. i = c? 1 : 0;) and declaration initializers are respected as well.

The screenshot above shows a first example where a potential TypeError is detected. Since there exists at least one control flow from v.length backwards to all reachable definitions of v,  such that one definition assigns null or undefined to v, a warning is issued telling that v may be undefined.

To make sure that the analysis will produce fast results, it is implemented within some limitations. One is that the analysis is done separately for each body of a function, method, etc. (i.e. intra-procedural analysis). Hence it lacks knowledge of variables that cross the borders of these bodies such as the return value of a nested function call. In addition, property variables (such as v.length) are not analyzed since this would require the analysis to be context sensitive to the receiver object (here v). However, these limitations are common for static analyses of statically typed languages and still allow to detect many problems regarding local variables and parameters.

Usually, the analysis makes optimistic assumptions. For instance it can happen that a local variable receives the value of a method call or another non-local variable. In this situation the analysis assumes this value is neither null nor undefined. The same is true for function parameters. Only when there are distinct indications in the source code for a value of a local variable to be null or undefined, the analysis will issue a warning.



Sometimes the programmer knows that a variable may be null or undefined and hence checks the variable explicitly, for instance using if (v) {...}. As a result this check disables the warning in the then-branch that complies to the execution semantics.

As shown in the screenshot above, neither at the expression w.length < 1 nor at the statement return w.length; a warning is shown. Of course, the else-branch of such a check would consequently always indicate a warning when a property of variable v is accessed. Checks for conditional expressions and binary logical expressions (e.g. v && v.length) are also supported. A reader might think: "In case w is null the expression w.length would fail." True, but in this example the analysis detects the value of w being undefined. In case null might have been assigned to w e.g. in an if-condition before, the analysis will issue a warning of w being null at the two w.length expressions.

Data Flow

There are situations where the value of a variable is null or undefined due to a previous assignment of a variable which may have been null or undefined before, like shown in the example above. Then, the null/undefined dereference problem occurs later when a property is accessed. Since the analysis respects data flow, it can follow the subsequent assignments. Hence a warning is shown at a property access indicating the null or undefined problem. Moreover, the warning also indicates the source of the null or undefined value which would be the variable w in the example above.

by Marcus Mews

by Project N4JS ( at September 20, 2018 12:39 PM

Get Acquainted With Sprotty at EclipseCon Europe

by Anonymous at September 20, 2018 11:40 AM

by Jan Koehnlein

Sprotty is a graphical framework that allows interactive diagrams in web-applications. It has a strong emphasis on usability, customizability and modern rendering. While being completely usable in standalone applications, Sprotty is also very easy to use in a distributed client-server environment. As such, it nicely plays the graphical counterpart in the Language Server Protocol.

by Anonymous at September 20, 2018 11:40 AM

Sponsor Testimonial: Typefox

by Anonymous at September 20, 2018 11:30 AM

Autumn time is EclipseCon time! Eclipse has evolved from a pure Java IDE, over a platform for tool integration on the desktop, towards an incubation tank for modern cloud-based development tooling. If you search for the place where all flavors of development tools and frameworks are concentrating, it’s here. We are happy that our latest cloud-based endeavors, Theia and Sprotty, found a home under the Eclipse umbrella.

by Anonymous at September 20, 2018 11:30 AM

Welcoming GlassFish to the Eclipse Foundation

September 19, 2018 07:30 PM

A major milestone was achieved yesterday! The GlassFish code from Oracle made its home in the Eclipse Foundation's Git repositories, starting a new era of Eclipse GlassFish.

September 19, 2018 07:30 PM

EMF Forms and EMF Client Platform 1.18.0 released!

by Jonas Helming and Maximilian Koegel at September 19, 2018 03:14 PM

We are happy to announce that with the Eclipse Release 2018-09, we have also shipped  EMF Forms and EMF Client Platform 1.18.0!

We want to thank our continuously active team of 11 contributors (41 contributors overall) for completing 50 bug fixes and features. EMF Forms continues to be one of the most active projects at Eclipse with a very stable development activity:

As announced during the 1.17.0 release, we have added a new service for adopters. The development team uses a defined  “Test” tag on important bug reports. In general, the “Test” keyword highlights bug reports, which should definitely be looked at and tested in detail by all adopters when updating to a new version. Please see more details in this announcement. All relevant “test” bug reports in 1.18.0 can be found here.

Please note, that due to the new release cadence of the Eclipse release train, there will be 4 releases per year for EMF Forms and EMF Client Platform from now on, too. As a consequence, we will be able to publish new features and improvements faster. The next release, 2018-12 is already due in December (19th).

Further, kindly continue to ask questions in the newsgroup and file Bug Reports.

In case you don’t know EMF Forms: It is a framework focused on the creation of form-based UIs. EMF Client Platform is designed to support the development of applications based on an EMF data model. If you are not yet familiar with EMF Forms, please refer to this tutorial for an introduction.

Both of these frameworks are part of the Eclipse Modeling Tools Photon package, but you can also find the new release on our download pages:

As always, we will also blog about new features of the EMF Forms / ECP 1.18.0 release in the upcoming weeks! Please follow this blog or follow us on twitter for notifications about new posts.

by Jonas Helming and Maximilian Koegel at September 19, 2018 03:14 PM

Papyrus IC at Models 2018

by tevirselrahc at September 19, 2018 02:05 PM

It’s official! The Papyrus IC is a sponsor of Models 2018.

It’s members and users will be there to show me to anyone interested – Please go meet them so they don’t feel too alone out there!

I do not have the details yet, but I will be sure to pressure my minions to get me their game plans so I can let you all know!

by tevirselrahc at September 19, 2018 02:05 PM

Apache Camel Java DSL in combination Eclipse Kura Wires

by Jens Reimann at September 19, 2018 08:30 AM

In part #1 and part #2, we saw how easy it is to interface Apache Camel with Kura Wires. Simply by re-using some existing functionality. A few lines of XML, Groovy and you can already build an IoT solution based on the Camel ecosystem and the Eclipse Kura runtime. This part will focus on the Java DSL of Apache Camel.

It will also take into account, that when you develop and deploy an application, you need some kind of development, test and integration environment. When you build something, no matter how big, based on Camel or Kura Wires, you do want to test it. You want to have unit tests, and the capability to automatically test if your solution works, or still works after you made changes.

Using Kura Wires alone, this can be a problem. But Camel offers you a way to easily run your solution in a local IDE, debugging the whole process. You can have extra support for debugging Camel specific constructs like routes and endpoints. Camel has support for JUnit and e.g. using the “seda” endpoints, you can in create an abstraction layer between Camel and Wires.

The goal

I’ll make this one up (and yes, let’s try to keep it realistic). We have a device, and his device allows to set two parameters for its operation (P1 and P2, both floating points). Now we already have the device connection set up in Kura. Maybe using Modbus, or something else. Kura can talk to it using Kura Wires and that is all that counts.

Now we do get two additional requirements. There is some kind of operating panel next to the device, which should allow viewing and setting those parameters locally. Also, those parameters should be accessible, using IEC 60870-5-104, for an additional device, right next to the Kura gateway.

All of those operations have to be local only, and still work when no connection to the cloud is possible. But of course, we don’t want to lose the ability to monitor the parameters from our cloud system.

The operator panel will, of course, be programmed in the newest and hippest Web UI technology possible. It is super easy to fire a few HTTP API calls and encode everything in JSON. While, at the same time, the IEC 60870 layer has no idea about complex data structures. The panel application will send a full update of both parameters, while the 60870 client, due to the nature of this protocol, will only send one parameter at a time.

Doesn’t too unrealistic, does it?

The project structure

The full project source code is available at ctron/kura-examples, on GitHub. So this blog post will only focus on some important spots of the whole project.

The project is a standard Maven project, and thus has the typical project structure:

Maven Camel project structure

There are only three important differences to a standard Java Maven project:

The packaging type is bundle, which requires the maven-bundle-plugin. It will create an OSGi bundle JAR, instead of a plain JAR file. This is required as the Kura IoT gateway is based on OSGi.

We will create a “DP” package at the end of the build, using the OSGi DP Maven Plugin. This package can directly be uploaded to the Kura instance. As this plugin does include direct dependencies, but doesn’t include transient dependencies (on purpose), the project declares a few dependencies as “provided” to prevent them from being re-packaged in the final DP package.

The project uses the maven-antrun-plugin to download and unpack the static Swagger UI resources. Swagger UI is just a convenience for playing around with the REST API later on. Camel will take care of creating the OpenAPI (Swagger) JSON description, even if the SwaggerUI part is removed. So in a production setup, you most likely would not add Swagger UI to the deployment.

Starting it up

The project has three entry points:

  • CamelApplicationComponent is the OSGi service, which will be managed by the OSGi service component runtime (SCR) when the component is uploaded to Kura.
  • TestApplication is a local test application, which is intended to be started from the local IDE for manual testing.
  • CamelApplicationComponentTest is the JUnit 4 based test for testing the Camel routes.

All three entry points will have a slightly different creation process for the Camel Context. This is simply due to the fact that different environments (like plain Java, OSGI and JUnit) have different requirements.

The routes configuration, which is the same for all entry points, is located in Routes.

Let’s have a quick look at the OSGi startup:

public void start(final BundleContext context) throws Exception {
  this.context = new OsgiDefaultCamelContext(context, SwaggerUi.createRegistry());
  this.context.addRoutes(new Routes(this.state));

  final Dictionary<String, Object> properties = new Hashtable<>();
  properties.put("", "camel.example.4");
  this.registration = context.registerService(CamelContext.class, this.context, properties);

Once the component is placed inside an OSGi container, the start method will be called and set up the Camel context. This is all pretty straightforward Camel code. As the last step, the Camel context will be registered with the OSGi service layer. Setting the service property in the process. This property is important, as we will, later on, use it to locate the Camel context from the Kura Wires graph by it.

The Java DSL routes

The routes configuration is pretty simple Camel stuff. First, the REST DSL will be used to configure the REST API. For example, the “GET” operation to receive the currently active parameters:

  .description("Get the current parameters")

This creates a get operation, which is being redirected to the internal “direct:getParameters” endpoint. Which is a way of forwarding that call to another Camel Route. This way Camel routes can be re-used from different callers.

Like for example the `direct:updateParameters` route, which will be called by all routes which want to update the parameters, no matter if that call originated in the IEC 60870, the REST or the Kura Wires component:

  .bean(this.state, "updateCurrentParameters")
  .to("direct:update.wires", "direct:update.iec.p1", "direct:update.iec.p2").end();

The route will forward the new parameters to the method updateCurrentParameters of the State class. This class is a plain Java class, holding the state and filling in null parameters with the current state. The result of this method will be forwarded to the other routes, for updating Kura Wires and the two parameters in the IEC 60870 data layer.

Trying it out

If you have Java and Maven installed, then you can simply compile the package by running:

cd camel/camel-example4
mvn clean package

This will compile, run the unit tests and create the .dp package in the folder target.

You can upload the package directly to your Kura instance. Please note that you do need the dependencies installed in part #1 of the tutorial. In additional you will need to install the following dependencies:


This will install the support for REST APIs, backed by Jetty. As Kura already contains Jetty, it only makes sense to re-use those existing components.

Once the component is deployed and started, you can navigate your web browser to http://:8090/api. This should bring up the Swagger UI, showing the API of the routes:

SwaggerUI of Camel example for Kura

Next, you can create the following components in the Kura wires graph:

  • Create a new “Camel consumer”, named consumer2
    • Set the ID to camel.example.4
    • Set the endpoint URI to seda:wiresOutput1
  • Create a new “Logger”, named logger2
    • Set it to “verbose”
  • Connect consumer2 with logger2
  • Click on “Apply” to activate the changes

Open the console of Kura and then open the Swagger UI page with the Web browser. Click on ““Try Out” of the “PUT” operation, enter some new values for setpoint1 and/or setpoint2 and click on the blue “Execute” button.

In the console of Kura you should see the following output:

2018-09-17T13:35:49,589 [Camel (camel-10) thread #27 - seda://wiresOutput1] INFO  o.e.k.i.w.l.Logger - Received WireEnvelope from org.eclipse.kura.wire.camel.CamelConsume-1537188764126-1
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger - Record List content:
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -   Record content:
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -     P1 : 3.0
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -     P2 : 2.0
2018-09-17T13:35:49,589 […] INFO  o.e.k.i.w.l.Logger -

This is the result of the “Logger” component from Kura Wires. Which did receive the new parameter updates from the Camel Context, as they got triggered through the Web UI. At the same time, the IEC 60870 server would update all clients being subscribed to those data items.

Wrapping it up

The last part of this tutorial showed that, if the prep-prepared XML router component of Eclipse Kura, is not enough, then you can drop in your own and powerful replacements. Developing with all the bells and whistles of Apache Camel, and still integrate with Kura Wires if necessary.

The post Apache Camel Java DSL in combination Eclipse Kura Wires appeared first on ctron's blog.

by Jens Reimann at September 19, 2018 08:30 AM

Welcoming GlassFish to the Eclipse Foundation

by Tanja Obradovic at September 19, 2018 12:45 AM

A major milestone was achieved yesterday! The GlassFish code from Oracle made its home in the Eclipse Foundation's Git repositories (, starting a new era of Eclipse GlassFish. This is another step in making Jakarta EE a vehicle for innovation in cloud-native application development.

The Eclipse GlassFish application server is still based on the Java EE specification, and we have a ways to go to finalize our work on defining necessary processes and approaches when working with open source TCKs. With the arrival of this codebase, we can start contemplating our first steps once we open up Jakarta EE for community contributions.

You can use the PMC’s project status page to track the progress we’re making in migrating all of the projects related to Jakarta EE.

Thanks to all involved in this effort, especially the Oracle team behind this move.

by Tanja Obradovic at September 19, 2018 12:45 AM

Papyrus UMLLight is go!

by tevirselrahc at September 18, 2018 12:57 PM

There were already a few posts [here] and [here] in which we talked about the new Papyrus UMLLight variant. Well – it is one step closer to completion.

My sources tell me that the scope has been defined and that requirements have been written, and that a request for quotation has been created and will soon be published!

UPDATE: The scope should be similar to of OMG’s OCUP2 Foundation level content.

Stay tuned for more information through official channels!

And of course, you will know about it here!

by tevirselrahc at September 18, 2018 12:57 PM

Special B2B Event at ECE

by Anonymous at September 17, 2018 07:36 PM

An Eclipse Foundation membership is a unique opportunity for smaller businesses. To encourage these organizations to join the Foundation, we are offering a special membership-plus-conference-attendance package.

Part of the package is a special business-to-business (B2B) event at the conference that offers a way for companies to expand both their commercial and development networks.

To learn more about this offering, please email Marc Vloemans, Eclipse Foundation Director, Ecosystem Development.

by Anonymous at September 17, 2018 07:36 PM

Call for BoFs

by Anonymous at September 17, 2018 06:03 PM

Birds of a Feather (BoF) sessions will be on Tuesday, 23 October, in the evening. If you are thinking of organizing a BoF, please visit this page for more information, and for access to the submission form for pre-scheduled BoFs.

by Anonymous at September 17, 2018 06:03 PM

Sunny weather with Apache Camel and Kura Wires

by Jens Reimann at September 17, 2018 02:48 PM

Part #1 of the Apache Camel to Kura Wires integration tutorial did focus on pushing data from Kura Wires to Camel and processing it there. But part #1 already mentioned that it is also possible to pull in data from Camel into Kura Wires.

Apache Camel consumer node in Kura Wires


For the next step, you again need to install a Camel package, for interfacing with Open Weather Map: The installation follows the same way as already described in part #1.

In addition to the installation of the package, you will also need to create an account at and create an API key. You can select the free tier plan, it is more than enough for our example.

Back to Wires

Next, create a new Camel context, like before, and give it the ID “camel2”. Add the required component weather, the required language groovy and set the following XML router content (be sure to replace <appid> with your API token):

<routes xmlns="">


    <from uri="weather:dummy?appid=<YOUR API TOKEN>&amp;lat=48.1351&amp;lon=11.5820"/>
    <to uri="stream:out"/>

    <unmarshal><json library="Gson"></json></unmarshal>
    <convertBodyTo type="java.lang.Double"/>
    <to uri="stream:out"/>

    <transform><groovy>["TEMP": request.body-273.15]</groovy></transform>
    <to uri="stream:out"/>
    <to uri="seda:output1"/>



After applying the changes, you can create two new components in the Wire graph:

  • Create a new “Camel Consumer”, name it consumer1
    • Set the Camel context ID camel2
    • Set the endpoint URI seda:output1
  • Create a new “Logger”, name it logger1
    • Set it to “verbose”
  • Connect consumer1 with logger1
  • Click on “Apply” to activate the changes

What does it do?

What this Camel context does, is to first start polling information from the Open Weather Map API. It requests with a manually provided GPS location, Munich.

It then parses the JSON, so that we can work with the data. Then it extracts the current temperature from the rather complex Open Weather Map structure. Of course, we could also use a different approach and extract additional or other information.

The extracted value could still be a number, represented internally by a string. So we ask Camel to ensure that the body of the message gets converted to a Double. If the body already is a double, then nothing will be done. But, if necessary, Camel will pull in its type converter system and optionally convert e.g. a string to a double by parsing it.

Now the body contains the raw value, as a Java double. But we still have two issues with that. The first one is, that the value is in degree Kelvin. Living in Germany, I would expect degree Celsius 😉 The second issue is, that Kura Wires requires some kind of key to that value, like a Map structure.

Fortunately, we easily can solve both issues with a short snippet of Groovy: ["TEMP": request.body-273.15]. This will take the message (request) body, convert it to degree Celsius, and using this as a value for the key TEMP in the newly created map.

Checking the result

As soon as you apply the changes, you should see some output on the console, which shows the incoming weather data:

{"coord":{"lon":11.58,"lat":48.14},"weather":[{"id":801,"main":"Clouds","description":"few clouds","icon":"02d"}],"base":"stations","main":{"temp":297.72,"pressure":1021,"humidity":53,"temp_min":295.15,"temp_max":299.15},"visibility":10000,"wind":{"speed":1.5},"clouds":{"all":20},"dt":1537190400,"sys":{"type":1,"id":4914,"message":0.0022,"country":"DE","sunrise":1537160035,"sunset":1537204873},"id":2867714,"name":"Muenchen","cod":200}

Every change, which should happen every second, shows three lines. First the raw JSON data, directly from the Open Weather Map API. Then the raw temperature in degree Kelvin, parsed by Camel and converted into a Java type already. Followed by the custom Map structure, created by the Groovy script. The beauty here is again, that you don’t need to fiddle around with custom data structures of the Kura Wires system, but can rely on standard data structures likes plain Java maps.

Looking at the Kura log file, which is by default /var/log/kura.log, you should see some output like this:

2018-09-17T13:57:10,117 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger - Received WireEnvelope from org.eclipse.kura.wire.camel.CamelConsume-1537188764126-1
2018-09-17T13:57:10,117 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger - Record List content:
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -   Record content:
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -     TEMP : 24.57000000000005
2018-09-17T13:57:10,118 [Camel (camel-15) thread #31 - seda://output1] INFO  o.e.k.i.w.l.Logger -

This shows the same value, as processed by the Camel context but received by Kura Wires.

Wrapping it up

Now, of course, a simple logger component isn’t really useful. But as you might now, Kura has the ability to connect to a GPS receiver. So you could also take the current position as an input to the Open Weather Map request. And instead of using my static GPS coordinates of Munich, you could query for the nearby weather information. So this might allow you to create some amazing IoT applications.

Stay tuned for Part #3, where we will look at a Camel based solution, which can run inside of Kura, as well as outside. Including actual unit tests, ready for continuous delivery.

The post Sunny weather with Apache Camel and Kura Wires appeared first on ctron's blog.

by Jens Reimann at September 17, 2018 02:48 PM

Leveraging the power of Apache Camel in Eclipse Kura

by Jens Reimann at September 14, 2018 01:52 PM

With the upcoming version of Eclipse Kura 4, we will see some nice new features for the embedded Apache Camel runtime. This tutorial walks you through the Camel integration of Kura wires, which allows you to bridge both technologies, and leverage the power of Apache Camel for your solutions on the IoT gateway.

Kura Wires is a graph-oriented programming model of Eclipse Kura. It allows wiring up different components, like a Modbus client to the internal Kura Cloud Service. It is similar to Node-RED.

Apache Camel is a message-oriented integration platform with a rule-based routing approach. It has a huge eco-system of components, allowing to integrate numerous messaging endpoints, data formats, and scripting languages.

A graphical approach, like Kura Wires may be interesting for a single instance, which is manually administered. But assume that you want to re-deploy the same solution multiple times. In this case you would want to locally develop and test it. Have proper tooling like validation and debugging. And then you want to automatically package it and run a set of unit and integration tests. And only after that you would want to deploy this. This model is supported when you are using Apache Camel. There is a lot of tooling available, tutorials, training, books on how to work with Apache Camel. And you can make use of the over 100 components which Camel itself provides. In addition to that, you have a whole ecosystem around Apache Camel, which can extend this even more. So it is definitely worth a look.


As a prerequisite, you will need an instance of Kura 4. As this is currently not yet released, you can also use a snapshot build of Kura 3.3, which will later become Kura 4.

If you don’t want to set up a dedicated device just for playing around, you can always use the Kura container image and it e.g. with Docker. There is a short introduction on how to get started with this at the DockerHub repository:

Starting a new Kura instance is as easy as:

docker run -ti ctron/kura:develop -p 8080:8080

The following tutorial assumes that you have already set up Kura, and started with a fresh instance.

Baby Steps

The first step we take is to create a very simple, empty, Camel Context and hook and directly hook up a Camel endpoint without further configuration.

New Camel Context

As a first step, we create a new XML Router Camel context:

  • Open the Kura Web UI
  • Click on the “+” button next to the services search box
  • Select the org.eclipse.kura.camel.xml.XmlRouterComponent factory
  • Enter the name camel1
  • Press “Submit”

New Camel Context Component

A new service should appear in the left side navigation area. Sometimes it happens that the service does not show up, but reloading the Web UI will reveal the newly created service.

Now select the service and edit the newly created context. Clear out the “Router XML” and only leave the root element:

<routes xmlns="">

In the field “Required Camel Components” add the stream component. Click on “Apply” to activate the changes. This will configure the Camel context to have no routes, but wait for the stream component to be present in the OSGi runtime. The stream component is a default component, provided by the Eclipse Kura Camel runtime. The Camel context should be ready immediately and will be registered as an OSGi service for others to consume.

The Wires Graph

The next step is to configure the Kura Wires graph:

  • Switch to “Wire Graph” in the navigation pane
  • Add a new “Timer” component named timer1
    • Configure the component to fire every second
  • Add a new “Camel Producer” named producer1
    • Set the Context ID field of the component to camel1
    • Set the endpoint URI to stream:out
  • Connect the nodes timer1 and producer1
  • Click on Apply to activate the changes

If you look at the console of the Kura instance, then you should see something like this:


Note: If you are running Kura on an actual device, then the output might be in the file /var/log/kura-console.log.

What is happening is, that the Kura wires timer component will trigger a Wires event every second. That event is passed along to the Camel endpoint stream:out in the Camel context camel1. This isn’t using any Camel routes yet. But this is a basic integration, which allows you to access all available Camel endpoints directly from Kura Wires.

Producer, Consumer, Processor

In addition to the “Producer” component, it is also possible to use the “Consumer”, or the “Processor”. The Consumer takes events from the Camel context and forwards them to the Kura Wires graph. While the “Processor” takes an event from the Wire Graph, processes it using Camel, and passes along the result to Wires again:

For Producer and Consumer, this would be a unidirectional message exchange from a Camel point of view. The Processor component would use an “in”/”out” message exchange, which is more like “request/response”. Of course that only makes sense when you have an endpoint which actually hands back a response, like the HTTP client endpoint.

In the following sections, we will see that in most cases there will be a more complex route set up that the Camel Wire component would interact with, proxied by a seda Camel component. Still, the “in”, “out” flow of the Camel message exchange would be end-to-end between whatever endpoint you have and the Wires graph.

Getting professional

Apache Camel mostly uses the concept of routes. And while accessing an endpoint directly from the Kura Camel component technically works, I wouldn’t recommend it. Mainly due to the fact that you would be missing an abstraction layer, there is no way to inject anything between the Kura Wires component and the final destination at the Camel endpoint. You directly hook up Kura Wires with the endpoint and thus lose all ways that Camel allows you to work with your data.

So as a first step, let’s decouple the Camel endpoint from Kura Wires and provide an API for our Camel Context.

In the camel1 configurations screen, change the “Router XML” to:

<routes xmlns="">
        <from uri="seda:input1"/>
        <to uri="stream:out"/>

Then configure the producer1 component in the Wire Graph to use the “Endpoint URI” seda:input1 instead of directly using stream:out.

If everything is right, then you should still see the same output on the Kura console, but now Wires and Camel are decoupled and properly interfaced using an internal event queue, which allows us to use Camel routes for the following steps.

One benefit of this approach also is that you can now take the XML route definitions outside of Kura and test them in your local IDE. There are various IDE extensions for Eclipse, IntelliJ and Visual Studio, which can help to work with Camel XML route definitions. And of course, there are the JBoss Tools as well ;-). So you can easily test the routes outside of a running Kura instance and feed in emulated Kura Wires events using the seda endpoints.


This first example already shows a common problem, when working with data, and even so for IoT use cases. The output of org.eclipse.kura.wire.WireEnvelope@3e0cef10 is definitely not what is of much use. But Camel is great a converting data, so let’s make use of that.

As a first step we need to enable the JSON support for Camel:

  • Navigate to “Packages”
  • Click on “Install/Upgrade”
  • Enter the URL:
  • Click on “Submit”

After a while, the package de.dentrassi.kura.addons.gson should appear in the list of installed packages. It may happen that the list doesn’t properly refresh. Clicking on “refresh” or reloading the Web page will help.

Instead of downloading the package directly to the Kura installation you can also download the file to your local machine and then upload it by providing the file in the “Install/Upgrade” dialog box.

As a next step, you need to change the “Router XML” of the Camel context camel1 to the following configuration:

<routes xmlns="">
        <from uri="seda:input1"/>
        <marshal><json library="Gson"/></marshal>
        <to uri="stream:out"/>

In the Kura console you will now see that we successfully transformed the internal Kura Wires data format to simple JSON:


This change did intercept the internal Kura wires objects and serialized them into proper JSON structures. The following step simply appends the content with a “newline” character in order to have a more readable output on the command line.

Transforming data

Depending on your IoT use case, transforming data can become rather complex. Camel is good at handling this. Transforming, filtering, splitting, aggregating, … for this tutorial I want to stick to a rather simple example, in order to focus in the integration between Kura and Camel, and less on the powers of Camel itself.

As the next step will use the “Groovy” script language to transform data, we will need to install an additional package using the same way as before:

Then go ahead and modify the “Router XML” to include a transformation step, add the following content before the JSON conversion:

return  ["value": new Random().nextInt(10), "timer": request.body.identification ];

The full XML context should now be:

<routes xmlns="">
        <from uri="seda:input1"/>
        return  ["value": new Random().nextInt(10), "timer": request.body.identification ];
        <marshal><json library="Gson"/></marshal>
        <to uri="stream:out"/>

After applying the changes, the output on the console should change to something like:


As you can see, we now created a new data structure, based on generated content and based on the original Kura Wires event information.

Off to the Eclipse Hono HTTP Adapter

Printing out JSON to the console is nice, but let’s get a bit more professional. Yes, Kura allows you to use its Kura specific MQTT data format. But what we want to send this piece of JSON to some HTTP endpoint, like the Eclipse Hono HTTP protocol adapter?

Camel has a huge variety of endpoints for connecting to various APIs, transport mechanisms and protocols. I doubt you directly would like your IoT gateway to contact Salesforce or Twitter, but using OPC UA, MQTT, HTTP, IEC 60870, might be a reasonable use case for IoT.

As a first step, we need to install Camel HTTP endpoint support:

The next step requires an instance of Eclipse Hono, thankfully there is a Hono sandbox server running at

In the XML Router we need two steps for this. You can add them after the to element, so that we still see the JSON on the command line:

<setHeader headerName=”Content-Type”><constant>application/json</constant></setHeader>
<to uri="https4://;authUsername=sensor1@DEFAULT_TENANT&amp;authPassword=hono-secret"/>

The first step sets the content type to application/json, which is passed along by Hono to the AMQP network.

Yes, it really is http4://, this is not a typo but the Camel endpoint using Apache HttpClient 4.

You may need to register the device with Hono before actually publishing data to the instance. Also, it is necessary that a consumer is attached, which receives the data. Hono rejects devices publish data if no consumer is attached. Also see:

If you are using a custom deployment of Hono using the OpenShift S2I approach, then the to URL would look more like:

<to uri="https4://;authUsername=sensor1@DEFAULT_TENANT&amp;authPassword=hono-secret"/>

Wrapping it up

What we have seen so far is that, with a few lines of XML, it is possible to interface with Kura Wires, and start processing data that was originally not supported by Kura, sending to a target that also isn’t supported by Kura. On for that we only used a few lines of XML.

In addition to that, you can test and develop everything in a local, confined space. Without having to worry too much about actually running a Kura instance.

In Part #2, we will have a look at ways to get data from Camel back into Kura Wires. And in Part #3 of this tutorial, we will continue with this approach and develop a Camel based solution, which can run inside of Kura, as well as outside, including actual unit tests.

The post Leveraging the power of Apache Camel in Eclipse Kura appeared first on ctron's blog.

by Jens Reimann at September 14, 2018 01:52 PM

Sponsor testimonial: Jonas Helming on EclipseSource @ EclipseCon

by Anonymous at September 14, 2018 11:54 AM

Learn more about the EclipseSource contributions to the program on themes such as the Eclipse Theia platform, modeling tools, Eclipse 4 and general web-related topics.

Q - If you had to choose a theme to watch at the conference, what would it be?

A new trending topic at EclipseCon is definitely the growing interest into web-based tools. It is interesting for projects, whether web-based tooling is already a valid alternative and if so when and how to migrate. A lot of this interest is focussed around Eclipse Theia ..

by Anonymous at September 14, 2018 11:54 AM

An $8.7 Billion Shared Investment: Sizing the Economic Value of Eclipse Community Collaboration

September 13, 2018 02:30 PM

What is the value of the code contributed by the Eclipse community? We estimate that the roughly 162 million total physical source lines of code in Eclipse repositories represent a $8.7 billion USD shared technology investment by our community.

September 13, 2018 02:30 PM

JBoss Tools 4.9.0.AM3 for Eclipse 2018-09 M2

by jeffmaury at September 13, 2018 09:39 AM

Happy to announce 4.9.0.AM3 (Developer Milestone 3) build for Eclipse 2018-09 M2.

Downloads available at JBoss Tools 4.9.0 AM3.

What is New?

Full info is at this page. Some highlights are below.


Server Tools

Wildfly 14 Server Adapter

A server adapter has been added to work with Wildfly 14. It adds support for Java EE 8.

Forge Tools

Forge Runtime updated to 3.9.1.Final

The included Forge runtime is now 3.9.1.Final. Read the official announcement here.

Fuse Tooling

Know issues

A regression has been introduced touching all functionalities using Jaxb. It includes:

  • Variable content display in debug

  • Data Transformation wizard

  • Tracing Camel route via Jolokia Connection

It may affect other functionalities. In this case, you will have this kind of error in log:

          at javax.xml.bind.ContextFinder.handleClassCastException(

Please note that it has been already fixed on nightly build


Jeff Maury

by jeffmaury at September 13, 2018 09:39 AM

Introducing our keynote speakers

by Anonymous at September 12, 2018 10:04 AM

Hirash Pillay, Global Head, Community Architecture and Leadership at RedHat - Lessons on Open Source from a 25-Year-Old Company

Tony Walsh, European Space Agency and Hristo Indzhov, Telespazio-Vega Deutschland - Flying to Jupiter with OSGi

Amanda Whaley, Director of Developer Experience & Developer Advocacy for Cisco DevNet -  Marie Curie, Open Source, Kickstarter, and Women in Tech

by Anonymous at September 12, 2018 10:04 AM