DDevelopment & Design

Karaf configuration as Groovy file

IntroductionBy deafault, Apache Karaf keeps configuration for bundles in the etc directory as flat properties files. We can override configuration for the storing mechanism by providing own implementation of the org.apache.felix.cm.PersistenceManager i…

Introduction

By deafault, Apache Karaf keeps configuration for bundles in the etc directory as flat properties files. We can override configuration for the storing mechanism by providing own implementation of the org.apache.felix.cm.PersistenceManager interface and use much more readable format for bundle properties, e. g. groovy config.

Turning off built-in Karaf persistence

As we can read in Karaf documentation:

Apache Karaf persists configuration using own persistence manager in case of when available persistence managers do not support that.

We will use our custom implementation of persistence, so Karaf persistence is not needed. We can turn it off by setting variable storage to an empty value:

$ cat etc/org.apache.karaf.config.cfg
storage=

This option is available since version 4.1.3 when this issue was resolved.

Registering custom Persistence Manager

First we have to create and register an OSGi service implementing org.apache.felix.cm.PersistenceManager. If we build and install the bundle with such service while Karaf is running (e.g. by putting jar in the deploy directory), then we should have at least two PersistenceManager services registered:

karaf@root()> ls org.apache.felix.cm.PersistenceManager
[org.apache.felix.cm.PersistenceManager]
----------------------------------------
 service.bundleid = 7
 service.description = Platform Filesystem Persistence Manager
 service.id = 14
 service.pid = org.apache.felix.cm.file.FilePersistenceManager
 service.ranking = -2147483648
 service.scope = singleton
 service.vendor = Apache Software Foundation
Provided by :
 Apache Felix Configuration Admin Service (7)
Used by:
 Apache Felix Configuration Admin Service (7)

[org.apache.felix.cm.PersistenceManager]
----------------------------------------
 osgi.service.blueprint.compname = groovyConfigPersistenceManager
 service.bundleid = 56
 service.id = 117
 service.pid = com.github.alien11689.osgi.util.groovyconfig.impl.GroovyConfigPersistenceManager
 service.ranking = 100
 service.scope = bundle
Provided by :
 groovy-config (56)
Used by:
 Apache Felix Configuration Admin Service (7)

Loaded configurations will be cached by configuration admin. We can use org.apache.felix.cm.NotCachablePersistenceManager interface if we want to implement custom caching strategy.

Creating a new properties file

Let’s create a new properties file in groovy, e.g:

$ cat etc/com.github.alien11689.test1.groovy
a = '7'
b {
    c {
        d = 1
        e = 2
    }
    z = 9
}
x.y.z='test'

If we search for properties with pid com.github.alien11689.test1, Karaf will find these.

karaf@root()> config:list '(service.pid=com.github.alien11689.test1)'
----------------------------------------------------------------
Pid:            com.github.alien11689.test1
BundleLocation: null
Properties:
   a = 7
   b.c.d = 1
   b.c.e = 2
   b.z = 9
   service.pid = com.github.alien11689.test1
   x.y.z = test

If we make any change to the file they won’t be mapped to properties, because there are no file watchers defined for it.

We could manage such properties using Karaf commands instead.

Managing configuration via Karaf commands

We can define a new pid using Karaf commands:

karaf@root()> config:property-set -p com.github.alien11689.test2 f.a 6
karaf@root()> config:property-set -p com.github.alien11689.test2 f.b 'test'

Since our PersistenceManager has higher service.ranking (100 > -2147483648), new pid will be stored as a groovy file:

$ cat etc/com.github.alien11689.test2.groovy
f {
    b='test'
    a='6'
}

We can also change/remove properties or remove the whole configuration pid using karaf commands and it will all be mapped to groovy configuration files.

Sources

Sources are available on github.

— Previous article

Hamming Error Correction with Kotlin - part 2

Next article —

Kotlin Type-Inference Puzzler

You May Also Like
DDevelopment & Design

Grails render as JSON catch

One of a reasons your controller doesn't render a proper response in JSON format might be wrong package name that you use. It is easy to overlook. Import are on top of a file, you look at your code and everything seems to be fine. Except response is still not in JSON format.

Consider this simple controller:

class RestJsonCatchController {
def grailsJson() {
render([first: 'foo', second: 5] as grails.converters.JSON)
    }

def netSfJson() {
render([first: 'foo', second: 5] as net.sf.json.JSON)
    }
}

And now, with finger crossed... We have a winner!

$ curl localhost:8080/example/restJsonCatch/grailsJson
{"first":"foo","second":5}
$ curl localhost:8080/example/restJsonCatch/netSfJson
{first=foo, second=5}

As you can see only grails.converters.JSON converts your response to JSON format. There is no such converter for net.sf.json.JSON, so Grails has no converter to apply and it renders Map normally.

Conclusion: always carefully look at your imports if you're working with JSON in Grails!

Edit: Burt suggested that this is a bug. I've submitted JIRA issue here: GRAILS-9622 render as class that is not a codec should throw exception