Frequently Asked Questions
Why do I get an "Unknown protocol: http" exception when I run Felix on a non-Sun JRE?
Felix installs the URL Handlers service by default. If you do not want this service you can disable it, by setting the felix.service.urlhandlers property to false in the config.properties file. It is not recommended to disable this, but the main reason for doing so it because the URL Handlers implementation invokes methods to set the singleton factories for URL stream and content handler factories. Assuming that you want to use URL Handlers service, you must configure it if you aren't running on the standard Sun JRE.
The URL Handlers service extends the standard Java URL stream and content handler mechanism to work in an OSGi environment. The way that built-in URL protocol and content handlers are discovered is by probing packages for the appropriate classes to handle the protocol/content. For example, the default package for Sun protocol handlers is:
If someone tries to create a URL for the "http" protocol, then the class to handle the protocol will be:
A similar process is followed for content handlers, whose default package is:
If you are running on a VM that is different than Sun's, then you must determine what are the default packages used for its protocol and content handlers. Once you know this information, then you can configure Felix to use those packages instead of the default one. You can configure Felix by setting the following system properties:
and
The value of these properties is a list of "|" delimited package names to be searched for protocol and content handlers, respectively. See the Java documentation for stream![]()
and content![]()
handlers for more information.
There are two ways to set these system properties. The first way is using the standard -D<property>=<value> syntax when executing java or if you are using Felix' standard Main.java launcher, you can put the system properties into the conf/system.properties file so that they get set automatically each time you execute Felix.
Should a bundle import its own exported packages?
In OSGi R3 this was always the case, since Export-Package implied Import-Package. It was a good idea then and is generally a good idea now.
The whole point is substitutability of providers.
If you import the packages you export, then the framework is free to choose a different provider of those packages for your bundle at resolve time, which means that your exports may go unused. However, this is a good thing, because the framework tries to minimize the number of active versions of a given package. The reason why this is a good thing is because it allows for higher levels of bundle interoperability. The more versions of a given package that are in use at any given time can lead to conflicts when trying to resolve bundle package dependencies and this also leads to partitioning of the service registry, since bundles can only see a single version of a given service package.
If your bundle only exports its packages, then it is forcing the framework to wire itself to its own version, which can result in more active version of the given package.
The main time you want to export only, is if your bundle is purely a library bundle, then its packages will only be used if they are needed. Another case might be if you have tightly coupled bundles sharing implementation packages. However, if your bundle will be started and especially if the exported packages define service interfaces or are referenced from service interfaces, then you will generally want to export and import them.
