access common property file inside bundle with osg

Question

I have an osgi application (in felix) with multiple bundles. There are some common property files in one bundle and the rest of the bundles need just use them.

We use maven and spring osgi, the property files are in resouces like:

<path to bundle>/src/main/resources/
    common.properties
    engine.properties
    ...

Maven builds them inside the bundle jar normally so they should be in an application classpath, but Spring has no access to them, this fails:

<context:property-placeholder location="classpath:common.properties" />

(tried classpath*: and other combinations)

I've read this and this

Is it really some global issue with osgi ideology and no standard way to get it working? Only hacks and workarounds like that or <osgix:cmProperties...>?

It concerns because it makes deployment harder and error-prone: you can't deploy property files inside jars with just mvn deploy as in normal application, - you'll have to manually copy them to the production box on each release.

Answer 1

I find that there is rarely a case where the properties file should be 'common'. Can't you break the contents of the properties file up and place them in the bundles that actually require them. The properties should be grouped by context and placed in the bundle which requires that context.

Similar in theory to not using a constants class or interface, which is considered an anti-pattern.

Answer 2

Another alternative here which I finally used - is placing property files to filesystem and just referencing them from spring (or other code) as file:path/to/common.props.

Answer 3

The best way to read common properties across all bundles is to use compendium service which is provided by spring DM.

Answer 4

With OSGi, there isn't a universal application classpath. Although the properties are on the classpath of the bundle which contains them, they're not necessarily on the classpath of the bundles using them.

It's a little bit ugly, but in general exporting the 'package' containing the property folders will make them accessible. In this case it looks like that would be '.', which is very ugly, but you could put them in a 'properties' directory (say), and then export a properties package. Bundles which use those properties would also need to import the properties package.

Alternatively, using the containing bundle's classloader to look up the resource will work, although I can't comment on what the Spring config for that would look like.