Hugues Malphettes wrote:
Client bundles that depend on slf4j state in their manifest: Import-Package: org.slf4j The osgi container resolves this into a dependency on slf4j-api and everything works on the client side.
On the logger implementation side: we need logback-classic or another bundle that provides o.s.impl to be set to start automatically. slf4j logs with NOPLogger until logback-classic is started
By the big picture, I actually meant the role played by the osgi-container from an architectural point of view. Is it correct to suppose that the target platform for slf4j-osgi-api is some OSGi container, e.g. Spring DM, Eclipse or Glassfish v3, which manage the "application" as bundles? If we are going the OSGi way, and we assume the existence of an OSGi platform, I think we should tackle the much harder problem of logging separation [1]. It's a very serious problem which I think could be solved with help of OSGi (or maybe even OSGi is not enough.) [1] http://logback.qos.ch/manual/loggingSeparation.html