Because people want to use libraries that use jboss-logging in OSGi environments other than JBoss OSGi. needs to be on the boot class path. See answer from James Perkins. install/start/stop/update/uninstall supposed to work? 1. code has a dependency on jboss-logging, either through Import-Package or Require-Bundle 2. the OSGi resolver makes sure this code isn't run before the dependency on jboss-logging is met 3. at the latest when the code that required jboss-logging does Logger.getLogger the jboss-logging bundle gets activated, LoggerProviders gets initialized and a look up of the LoggerProvider implementation class happens. 4. A new version of jboss-logging can be installed at any time, it will just do the look up of the LoggerProvider implementation class again. Standard OSGi rules will apply which bundles the the new version of jboss-logging. Since jboss-logging is not an actual logging implementation loading multiple versions of it is fine. This isn't the case for implementations like Logback. If you have two versions of Logback installed that want to log into the same file this may cause a problem. Therefore only actual log implementations should be marked as singleton bundles, not jboss-logging itself. 5. As with any OSGi bundle jboss-logging should not be stopped until all bundles that depend on it transitively are stopped. Otherwise you have code that references objects and classes in a stopped bundle. Once they all have been stopped jboss-logging can be restared, uninstalled or updated. properly as bundle, or can it? It works fine. I have code here that runs it in Equinox and it runs fine. Cheers Philippe