PropertyFiles
From APIDesign
| Line 1: | Line 1: | ||
| - | Many systems store their configuration in some form of [[PropertyFiles|property files]]. Files which contain string ''key/value'' mappings. This is indeed an example from the [[APITypes]], as changes to these values influence behaviour of those systems. This may seem much more trivial form of an [[API]] than [[Java]] classes and their signatures and in some | + | Many systems store their configuration in some form of [[PropertyFiles|property files]]. Files which contain string ''key/value'' mappings. This is indeed an example from the [[APITypes]], as changes to these values influence behaviour of those systems. This may seem much more trivial form of an [[API]] than [[Java]] classes and their signatures and in some way it is, however the rules of proper [[APIDesignPatterns|API Design]] are still applicable: one needs to keep [[BackwardCompatibility]], be ready for [[API]] [[evolution]], etc. |
One commonly used ''property file'' in [[Java]] is the [[JAR]] manifest. It contains ''tag/value'' mappings for one main and many per entry sections. Many systems including [[NetBeans Runtime Container]] or [[OSGi]] recognize values of their own tags and based on them prepare runtime environment for the classes contained in the [[JAR]] file. Recently I was playing a bit with [[Felix]] and was trying to create a bundle (a [[JAR]] with [[OSGi]] manifest) that will require another bundle: | One commonly used ''property file'' in [[Java]] is the [[JAR]] manifest. It contains ''tag/value'' mappings for one main and many per entry sections. Many systems including [[NetBeans Runtime Container]] or [[OSGi]] recognize values of their own tags and based on them prepare runtime environment for the classes contained in the [[JAR]] file. Recently I was playing a bit with [[Felix]] and was trying to create a bundle (a [[JAR]] with [[OSGi]] manifest) that will require another bundle: | ||
Revision as of 10:17, 16 December 2008
Many systems store their configuration in some form of property files. Files which contain string key/value mappings. This is indeed an example from the APITypes, as changes to these values influence behaviour of those systems. This may seem much more trivial form of an API than Java classes and their signatures and in some way it is, however the rules of proper API Design are still applicable: one needs to keep BackwardCompatibility, be ready for API evolution, etc.
One commonly used property file in Java is the JAR manifest. It contains tag/value mappings for one main and many per entry sections. Many systems including NetBeans Runtime Container or OSGi recognize values of their own tags and based on them prepare runtime environment for the classes contained in the JAR file. Recently I was playing a bit with Felix and was trying to create a bundle (a JAR with OSGi manifest) that will require another bundle:
Manifest-Version: 1.0 Require-Bundle: does.no.exists;bundle-version="[1.0,2.0)" Export-Package: org.bar Bundle-Version: 1.1.0 Bundle-SymbolicName: org.bar
As the bundle does.no.exists does not exists, I would expect the system to refuse to start the org.bar bundle. To my biggest surprise, my bundle was successfully started. I've spend few days trying to find out what is wrong. Did I make a typo? No. Did I read the OSGi specification incorrectly? Neither. Is Felix broken? Let's debug it! Or rather not, this is not cluelessness! I do not want to be an expert at Felix, I am just an OSGi API user! So what is wrong?
At the end I decided to email Richard Hall, Felix maintainer and send him my org.bar bundle. In a minute I got an answer back, as he spotted the problem immediately, the following tag was missing:
Bundle-ManifestVersion: 2
After adding it, everything started to behave as expected. The bundle is now rejected, as the Require-Bundle dependency cannot be satisfied. It is easy to use an API if you resolve your problems by asking author of the specification. However this is probably not really scalable and there is something wrong with the OSGi manifest API.
Follow
