Koodihommia

In past year or so I've been watching dozens of tech talks about reactive architectures. Most of the time I have felt inspired by them but could not quite get a grasp on what a reactive architecture is really like. Sure, the list of gained benefits such like 100x increase in response times is convincing but not having the experienced that myself, it all seems a bit vague. I need something concrete. The funny thing is that for the last one and a half years I have been working on a message-driven, non-blocking component (service). The technology stack is at least partially modern, with AngularJS (Some might object, I know...), Vaadin with websocket push as the only server-client communication method and Akka. There is no Java EE or any heavy platform used but rather a customized version of Karaf OSGi container where we run the software as small modules. The UI is not locked at any point, the user can navigate at any time since there are no HTTP requests. Every end-user action resul

When OSGi modules are fabricated so that they have limited dependencies to other modules, the development process is a breeze. Changes to any single module reflect to a limited set of other modules which enables easy deployment and update of the running software. In the Karaf based project I'm working on, this is mostly the case: updating for example a bundle which is responsible for a certain UI view, only the corresponding view goes down for a couple of milliseconds and the page is automatically refreshed after that. We started seeing exceptions to this on places where there should not have been any "core" dependencies. When upgrading for example a bundle which exports message/model classes which are part of the Akka communication between the bundles, sometimes the whole karaf seems to go down. The message classes can be used by multiple bundles including the core ones but we started seeing this behavior happening when deploying also non-core Akka message bundles. Wha

It is not uncommon to have ClassNotFound exceptions thrown when developing applications inside OSGi world. LinkageErrors can be even seen as "normal" exceptions which can have minor effects on how the application works. Akka actors other hand really don't like linkage errors, more specifically, during message handling. If a linkage error is thrown, it will result to the whole actor system going down. Supervision strategies don't help here either, the linkage errors pass right through. To combat the problem, there are some options. The most obvious one is to wrap the actors receive method with try-catch clauses. You either do this is in every actor or create a superclass which delegates the receive to a safe method. Another option is to use compile-time weaved aspects. The actor library can be wrapped and the compiled classes can be then weaved. If using OSGi then the manifest entries need to be set correctly so that the actor classes are exported and for the ser

Switching to English... Using the Java API with Akka might result in somewhat ugly code, especially if using the UntypedActor classes. If an actor has many types of messages it can receive, it may result in long "if instanceof" chains. The situation can be improved by using AbstractActors or even TypedActors in some cases. There might be an alternative though. To make the code a bit prettier, one solution can be to loan the idea of traits from Scala. Java interfaces with default methods can be used to achieve similar behavior. Let's say we have an Actor A  with some messages [ B, C, D ] it expects. Instead of writing a long handleMessage method with all kinds of if statements, we can set the A to implement interface CTrait . The CTrait has a default method handleC which then handles the C typed message. The CTrait may also force the A to expose some methods so it can do it's job. Finally we need such a setup that handleC is called from A , preferably without

Apache Karaf on OSGi standardin täyttävä valmis paketti valikoituja OSGi bundleja. Näppärinä ominaisuuksina mainittakoon mm. Felix gogo shell ja feature filet. Feature fileillä voidaan määritellä mitkä bundlet asennetaan missäkin järjestyksessä. Olemme määrittäneet itse muutamia eri konfiguraatioita omaa softaa varten. Myös osasta karafin omista bundleista olemme hankkiutuneet eroon. Karafissa on myös hyödyllinen maven-plugin jolla voi tehdä kustomisoidun karaf paketin. Käytämme tätä ominaisuutta, jotta saamme rakennettua paketin joka sopii aina testiympäristöistä tuontantoon. Kaikki konfiguraatiot, bundlet ja itse ympäristö on yhdessä tar-paketissa jonka voi purkaa ja ajaa missä vaan Java 8 koneessa. Feature tiedostot ovat hyödyllisiä, mutta aiheuttavat myös harmaita hiuksia. Karaf parsiessaan ja asentaessaan bundleja (featureita) ei välttämättä anna kovin informatiivisia viestejä mikä on pielessä. Tämä tuli erityisen selväksi päivitettäessä karafia kolmosversiosta neloseen. M