3

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.

Community
  • 1
  • 1
yetanothercoder
  • 1,689
  • 4
  • 21
  • 43

4 Answers4

5

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.

Holly Cummins
  • 10,767
  • 3
  • 23
  • 25
  • _but you could put them in a 'properties' directory (say), and then export a properties package..._ - thanks, didn't hear about this way, though exporting prop folder as a java package, seems like another hack ) – yetanothercoder May 18 '12 at 07:45
  • I agree it feels like a hack. :) One way of thinking about it is that modularity means jars shouldn't be rooting around in the innards of other jars, without declaring an explicit dependency. Package exports work nicely for classes and are a bit clunky for properties, and maybe the lesson there is that there are cleaner techniques for common configuration than shared properties files; either expose a configuration service and can be shared in a cleaner way, or use Configuration Admin. The entry barrier for either of these is higher than a plain old properties file, of course. – Holly Cummins May 18 '12 at 10:48
  • I see, yes, osgi gets you one enterprise level up to avoid dealing with plain property files =) _either expose a configuration service and can be shared in a cleaner way, or use Configuration Admin. The entry barrier for either of these is higher.._ - I'm afraid not only entry barrier, but you'll get also performance overhead when you'll be referencing you property values via some configuration service from another bundle, I mean sm kind of serialization/proxying/reflection overhead here. – yetanothercoder May 18 '12 at 12:14
  • I'm marking it as answer because it seems more reasonable work-around, but personally I prefer another: placing common props in filesystem and referencing from spring as file:./path/to/common-props. – yetanothercoder May 21 '12 at 09:33
2

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

Damoder
  • 21
  • 1
0

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.

Robin
  • 24,062
  • 5
  • 49
  • 58
  • consider multiple bundles with an access to the same database - you'll have to hardcode the same db properties in each bundle? – yetanothercoder May 19 '12 at 07:13
  • For that particular case using a persistence bundle and JPA would probably be cleaner and easier. – Holly Cummins May 20 '12 at 05:12
  • If you need a common database then the best way is to configure a DataSource and publish it as an OSGi service. Then you user bundles can simply reference the service and do not have to know about the DB properties. See: http://www.liquid-reality.de/x/LYBk – Christian Schneider May 21 '12 at 09:57
0

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.

yetanothercoder
  • 1,689
  • 4
  • 21
  • 43