At times the need arises for developers or users to extend the functionalities of the Carbon servers. For an example, one might want to use a new Java library that implements a cool new protocol handling capabilitiescapability. The standard way to extend the Carbon server runtime , is to add those new libs as bundles in the $CARBONthe
More often than not, these third party libs comes come with their own config files. In a typical non-OSGi application those config files will be picked from the application classpath . (implementations can differ; however, it can share one common classpath across all the libs).
Carbon being an OSGi application , does not share a common classpath among its libraries. Each bundle in the environment has a unique bundle classLoader which resolves into a unique classpath. In such scenarios there are three possible solutions which are:
- Bundle the config files along with the library class files
This . This will ensure that config files always resides in the bundle classpath. The biggest disadvantage is that, you cannot edit the config files during server restarts.
- If the third party library accepts the config file path via a system property, we can set that system property prior to invocation of the library.
This This is a very clean approach.
- Bundle the config file as a fragment of the main library and attach them during the startup of the server.
Fragment will attach to its host bundle during runtime and will share the same bundleloader of host bundle. As a result, the host bundle will have the access to fragment bundles bundle resources (since it shares the classpath).
Follow the steps below to allow Carbon servers to convert your resources into fragment bundles and attach them to the relevant host bundles during server startup time.
A developer integrates a a
foo.jar bundle bundle with the Carbon server by adding it to $CARBONto
HOME>/repository/components/dropins. The bundles comes with foo.properties file that has to be changed according to the running environment. The developer decides to follow the third approach mentioned above, which is to separate out the the
config-files/resources and and load them as a fragment of the host bundle (
foo.jar) during the server startup.
- Create a directory named
The directory name is how the server derives the host bundle that it should attach to which the fragment bundle should be attached.
- Place the the
resources/configfiles files under the newly created created
- Start the server with with
- Upon executing the
sscommand command you should see the new fragment bundle named named
foo.config-1.0.0.jarthat that has the the
foo.jaras as its host.
The server created bundle (that was created from created from the developer given given
resources/properties files files) can be found in $CARBONin