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
_______________________________________________
slf4j-dev mailing list
[email protected]
http://qos.ch/mailman/listinfo/slf4j-dev
