[jboss-as7-dev] why is jboss-logging a bundle anyway

[Philippe Marschall]

 > why is jboss-logging a bundle anyway?

Because people want to use libraries that use jboss-logging in OSGi 
environments other than JBoss OSGi.

 > I thought due to its tight integration with the JDK logging system it 
needs to be on the boot class path.

See answer from James Perkins.

 > How is the jboss-logging bundle lifecycle 
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.

 > Would it not be better to ship it as a library if it can't work 
properly as bundle, or can it?

It works fine. I have code here that runs it in Equinox and it runs fine.

Cheers
Philippe