3
votes

I have a custom jar with a custom Main class, which starts the OSGi Framework and installs/starts the bundles. This main jar also includes a properties file.

Goal: I have a bundle A which should pick up the properties of this properties file of the main jar somehow.

My first attempt was to define a component in bundle A (using Apache Felix SCR/ Declarative Services) and retrieve the properties in its activate-method. This works so far that I'm getting the default value specified in the @Property-annotation.

But how can I now pass the properties of the properties file to this component?

Passing arguments to OSGi application mentions to use the Config Admin, but how can I use this in the Main class?

  • The Config Admin is in a bundle, not in the main jar, and the bundles are not installed in any specific order
  • The Main class doesn't know anything about the bundles it installs, let alone a specific service.pid.

Update:

I'm trying now an approach suggested by @vizier (which doesn't use Config Admin and thus doesn't have the mentioned issues):

  • define a service interface in the main jar (system bundle)
  • provide an implementation, which reads the property file (the properties file is in the same jar)
  • export the package X containing this service interface
  • bundle A then can import the package X and e.g. reference the service using Declarative Services

But in my bundle A I'm getting:

org.osgi.framework.BundleException: Unresolved constraint in bundle <bundle A> [14]: Unable to resolve 14.0: missing requirement [14.0] osgi.wiring.package; (&(osgi.wiring.package=<package X>)(version>=0.1.0)(!(version>=1.0.0)))
    at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826)
    at org.apache.felix.framework.Felix.startBundle(Felix.java:1868)
    at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191)
    at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLevelImpl.java:295)
    at java.lang.Thread.run(Thread.java:722)

Does the system bundle only export osgi packages even if some custom packages were added to Export-Package in the Manifest file? Or what is going wrong?

4

4 Answers

2
votes

As always, register a service ... The receive bundle (and any other bundle) can search for the service and read the properties. Since you're the framework launcher you can register any service you want through the Framework object you get from the Launching API.

In bnd(tools) I have a launcher. It uses the OSGi Launcher API to create the bundle, similar to what you describe. I pass the command line arguments as properties on a Launcher service. Look at https://github.com/bndtools/bnd/blob/master/biz.aQute.launcher/src/aQute/launcher/Launcher.java for an example.

You can of course also just get the Configuration Admin service through the Framework object and use it to register Configurations. It is quite easy (just actually done it) to define the configurations in JSON (or, dare I say it, XML) file and then read it and update Configuration Admin.

1
votes

You can make the jar containing the main class an OSGi bundle as well, and during startup you install this bundle together with the other bundles. Then you can let other bundles access the properties contained in your jar using a number of techniques, such as the followings:

  • provide a class for accessing the properties and integrate using module dependancy (Export-package/Import-package)
  • provide as service for accessing the properties
  • use Config Admin
1
votes

The simplest may be to make the jar with the properties file a fragment, with bundle A as the host.

Then the properties will be on the classpath of the bundle and can be easily read.

0
votes

We have a similar case in Apache Karaf. There we simply set the properties as java System properties and also give them to the framework. These are then available as properties in the OSGi bundle context. So this is nice for properties that are for the whole platform. See the project of the karaf starter: http://svn.apache.org/viewvc/karaf/trunk/main/

If you need properties in user bundles then using the config admin service is much nicer. It decouples the user bundle form the mechanism of retrieving the properties and also allows updates at runtime. There is a also the metatype service which allows to define the structure and meaning of the properties which allows nice forms for editing the properties.

I describe in two tutorials on my website how to use the config admin service: