Koodihommia

I've been working on a web shop integration project from time to time for last six months. The use case is that there are several different instances of a webshop (slave) and one master shop. All product information should be integrated from the master shop to the slaves on regular intervals. There are also some business rules applied to the products upon integration. The integration is set to happen on a certain time of day. It is a relatively long process because it checks through all the products in all shops. That's fine though, there is no requirements on how quick the integration should be. It should rather be a resource constrained process so it would not affect the users using the web shops. Originally I thought this would be a perfect use case for serverless application running in AWS Lambda for example. I also tried out OpenWhisk from IBM which can be run as a self-hosted serverless platform. While it would have been interesting to try out those technologies I ...

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 ...