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 session timeout without XML

This article shows clean, non hacky way of configuring featureful event listeners for Grails application servlet context. Feat. HttpSessionListener as a Spring bean example with session timeout depending on whether user account is premium or not.

Common approaches

Speaking of session timeout config in Grails, a default approach is to install templates with a command. This way we got direct access to web.xml file. Also more unnecessary files are created. Despite that unnecessary files are unnecessary, we should also remember some other common knowledge: XML is not for humans.

Another, a bit more hacky, way is to create mysterious scripts/_Events.groovy file. Inside of which, by using not less enigmatic closure: eventWebXmlEnd = { filename -> ... }, we can parse and hack into web.xml with a help of XmlSlurper.
Even though lot of Grails plugins do it similar way, still it’s not really straightforward, is it? Besides, where’s the IDE support? Hello!?

Examples of both above ways can be seen on StackOverflow.

Simpler and cleaner way

By adding just a single line to the already generated init closure we have it done:
class BootStrap {


    def init = { servletContext ->    

        servletContext.addListener(OurListenerClass)    

    }    

}

Allrighty, this is enough to avoid XML. Sweets are served after the main course though :)

Listener as a Spring bean

Let us assume we have a requirement. Set a longer session timeout for premium user account.
Users are authenticated upon session creation through SSO.

To easy meet the requirements just instantiate the CustomTimeoutSessionListener as Spring bean at resources.groovy. We also going to need some source of the user custom session timeout. Let say a ConfigService.
beans = {    

    customTimeoutSessionListener(CustomTimeoutSessionListener) {    

        configService = ref('configService')    

    }    

}

With such approach BootStrap.groovy has to by slightly modified. To keep control on listener instantation, instead of passing listener class type, Spring bean is injected by Grails and the instance passed:
class BootStrap {


    def customTimeoutSessionListener


    def init = { servletContext ->    

        servletContext.addListener(customTimeoutSessionListener)

    }    

}

An example CustomTimeoutSessionListener implementation can look like:
import javax.servlet.http.HttpSessionEvent    

import javax.servlet.http.HttpSessionListener    

import your.app.ConfigService    


class CustomTimeoutSessionListener implements HttpSessionListener {    


    ConfigService configService


    @Override    

    void sessionCreated(HttpSessionEvent httpSessionEvent) {    

        httpSessionEvent.session.maxInactiveInterval = configService.sessionTimeoutSeconds

    }    


    @Override    

    void sessionDestroyed(HttpSessionEvent httpSessionEvent) { /* nothing to implement */ }    

}
Having at hand all power of the Spring IoC this is surely a good place to load some persisted user’s account stuff into the session or to notify any other adequate bean about user presence.

Wait, what about the user context?

Honest answer is: that depends on your case. Yet here’s an example of getSessionTimeoutMinutes() implementation using Spring Security:
import org.springframework.security.core.context.SecurityContextHolder    


class ConfigService {


    static final int 3H = 3 * 60 * 60

    static final int QUARTER = 15 * 60


    int getSessionTimeoutSeconds() {    


        String username = SecurityContextHolder.context?.authentication?.principal    

        def account = Account.findByUsername(username)    


        return account?.premium ? 3H : QUARTER

    }    

}
This example is simplified. Does not contain much of defensive programming. Just an assumption that principal is already set and is a String - unique username. Thanks to Grails convention our ConfigService is transactional so the Account domain class can use GORM dynamic finder.
OK, config fetching implementation details are out of scope here anyway. You can get, load, fetch, obtain from wherever you like to. Domain persistence, principal object, role config, external file and so on...

Any gotchas?

There is one. When running grails test command, servletContext comes as some mocked class instance without addListener method. Thus we going to have a MissingMethodException when running tests :(

Solution is typical:
def init = { servletContext ->

    if (Environment.current != Environment.TEST) {    

        servletContext.addListener(customTimeoutSessionListener)    

    }    

}
An unnecessary obstacle if you ask me. Should I submit a Jira issue about that?

TL;DR

Just implement a HttpSessionListener. Create a Spring bean of the listener. Inject it into BootStrap.groovy and call servletContext.addListener(injectedListener).