Reading an OSGi config value

Question

I've got some code like this to read a value that could be set either with a sling:OsgiConfig node or after being set in the Felix UI...

@Component(immediate = true, metatype = true, label = "Dummy Service")
public class DummyService {
    @Property(label = "Dummy Service Value")
    public static final String DUMMY_VALUE = "dummyValue";
    private static String m_strDummyValue = "default value";

    public static String getDummyValue(){
        return m_strDummyValue;
    }

    @Activate
    protected void activate(ComponentContext context) {
        configure(context.getProperties());
    }

    @Deactivate
    protected void deactivate(ComponentContext context) {
    }

    @Modified
    protected void modified(ComponentContext componentContext) {
        configure(componentContext.getProperties());
    }

    public void updated(Dictionary properties) throws ConfigurationException {
        configure(properties);
    }

    private void configure(Dictionary properties) {
        m_strDummyValue = OsgiUtil.toString(properties.get(DUMMY_VALUE), null);
    }
}

And could be called in any consuming class as

DummyService.getDummyValue();

This is currently working in our development environment. It's also very similar to some code that another vendor wrote and is currently in production in the client environment, and seems to be working. However, I ran across this post OSGi component configurable via Apache Felix... which recommends against using a static accessor like this. Are there potential problems where getDummyValue() could return an incorrect value, or is the recommendation more about being philosophically consistent with OSGi's patterns?

score 1 · Answer 1 · answered Jun 20 '14 at 17:55

1

Generally statics are frowned upon especially in OSGi as it involves a tight code coupling. It would be better to have DummySerivce be an interface and your class implement it with the component being a service. Then others would reference your component's service. Once injected with the service, they can call the service's methods.

answered Jun 20 '14 at 17:55

BJ Hargrave

9,324
1
19
27

So, reading between the lines, I guess...is it fair to say that if I'm OK with the architectural consequences of that tight coupling, the static method approach should work? – joelt Jun 20 '14 at 20:41
Well, I'd say, it's just semantically wrong to mark a (per instance) configurable value as static - because it is not. Say in some future you may want to have multiple instances of `DummyService` for some reason (e.g. while hot-swapping), the static variable will cause unexpected behaviour. Why not leave it non-static in the first place? – benjamin Jun 22 '14 at 13:24

score 0 · Accepted Answer · answered Jun 23 '14 at 09:14

0

You shouldn't do this for one major reason: there is no guarantee that DummyService has been configured when you access the static method - in contrast with a service reference.

answered Jun 23 '14 at 09:14

Tassos Bassoukos

16,017
2
36
40

This is the kind of thing I was thinking. Can you elaborate on scenarios where this could occur? Race condition when the bundle is getting re-installed where the static reference could succeed before the activate method has run? – joelt Jun 26 '14 at 04:10

Reading an OSGi config value

2 Answers2