All posts by steinarbang

Simplified REST APIs from karaf using Jersey

I have written the Java class JerseyServlet which is intended as a base class for DS (Declarative Services) components providing Servlet services to the OSGi web whiteboard.

The JerseyServlet simplifies the approach outlined in Use Jersey to provide REST APIs from karaf applications.
Continue reading Simplified REST APIs from karaf using Jersey

My OSGi story

OSGi is a Java plugin framework and module system that were initially created for supporting embdedded applications in the automotive industry. OSGi also forms the foundations for the Eclipse IDE plugin model. The plugin model of OSGi consists of components waiting for services and starting and exposing services when all of the dependencies are satsified. A “service” in OSGi terminology, is a Java interface.

I first encountered OSGi in 2006. The company I worked from used OSGi as the basis for an ETL processing system implementing various processing elements as OSGi plugins plugging into the processing framework. Since writing OSGi activators (which was the state of the art for OSGi plugins back in the day) is kind of boring, we created a Dependency Injection system on top of OSGi.

Continue reading My OSGi story

Rewriting applications to use pax-jdbc-config and liquibase

After creating the post Pluggable databases for apache karaf applications I posted a link to the blog post in the karaf user mailing list, and the immediate response was, “why didn’t I just pax-jdbc-config instead?“.

The answer to that is that I didn’t know about pax-jdbc-config. I started using pax-jdbc in the summer of 2016, and started using apache karaf in the autumn of 2016 and pax-jdbc-config didn’t exist then (or at least: not as complete and usable as it became in 2017), and any announcement that has gone past since then, has not registered.

Continue reading Rewriting applications to use pax-jdbc-config and liquibase

A Java programmer’s guide to delivering webapp frontends

When I started investigating (googling) web frontends, I found tutorials for various frameworks and I found tutorials using node.js to deliver frontends to web browsers on localhost.

What I did not find, was something telling me how I should pack up and deliver the webapp frontend from my production system, so that comes here:

  1. A web application frontend  is a piece of javascript code, that builds its user interface by rebuilding the DOM tree of the webpage that loaded it
  2. The javascript needed for a webapp is packaged up as a big javascript file, typically named bundle.js,
  3. The initial HTML file references bundle.js
  4. The initial HTML file also contains an element that matches what the javascript code expects to be its start element (i.e. the point in the DOM of the parsed HTML file, where the javascript program starts rebuilding its own DOM)

Continue reading A Java programmer’s guide to delivering webapp frontends

Faking a debian repository for package development

I use aptly to deliver my unofficial debian packages both to myself and others that might be interested.

However I’ve found that using aptly to do package development is a bad idea, because you can’t (by design, probably) overwrite packages in an aptly archive.  You can only create new versions.

For some installation tests it’s OK to use “dpkg –install”. But if your package needs to pull in depdencies, or if you wish to test a package upgrade, you need to use APT.

This article explains how to create a fake debian repository for use in package development. Continue reading Faking a debian repository for package development