Re: [slf4j-dev] slf4j-osgi-api module
On Thu, Nov 26, 2009 at 2:25 AM, Ceki Gülcü <ceki@qos.ch> wrote:
Hello Hugues,
Hi! Thanks for your interest in this experiment to get rid of the cyclic dependency between slf4j-api and a bundle that provides an slf4j implementation (bug #75).
From what I could gather looking at the slf4j-api-osgi module, it looks like the slf4j-api-osgi module is responsible for binding slf4j-api with the underlying logging framework using the resolution functionality offered by OSGi. Given that slf4j-api-osgi module itself exports the org.slf4j.impl package, I was wondering how you were going to avoid recursing endlessly into slf4j-api-osgi or mistakenly export the org.slf4j.impl package found in slf4j-api-osgi instead of a real/desired implementation. slf4j-api-osgi avoids that undesirable predicament by exporting the o.s.impl package only if the exporting bundle is not itself. It also registers listeners in case the desired bundle is installed later on. Nice.
Thanks! I tested this scenario to make sure the listeners are working as expected: - start everything with logback-classic - do some logging: loggers are provided by logback-classic - stop logback-classic. - get a new Logger returns the NOP-logger - start logback-classic again - getting a new logger return loggers provided by logback classic again.
However, I still don't see what happens if the slf4j-api-osgi is exported by another bundle *before* the slf4j-api-osgi bundle is installed and before it has a chance to act.
OSGi will only start a bundle once all its dependencies are resolved as bundles and those are started. As all bundles that provide o.s.impl import the package o.slf4j; it is guaranteed that slf4j-api is installed first before them. slf4j-api-osgi bundle is a fragment hosted by slf4j-api. When slf4j-api is installed by the OSGi container the slf4j-api-osgi is "attached" to slf4j-api. The OSGi spec says that fragments are not started, they are "attached" to their host bundle. Hence when slf4j-api is started we also have slf4j-api-osgi acting inside it. The org.slf4j.impl package provided by slf4j-api-osgi is placed in the very same classloader than org.slf4j.Logger So when org.slf4j.LoggerFactory imports org.slf4j.impl.StaticLoggerBinder it finds the one provided by slf4j-api-osgi. There is another way to achieve the exact same situation: place the classes of slf4j-api-osgi as a jar embedded inside slf4j-api. It is taken into account only by osgi and it would save us having to carry a new jar for the OSGi support.
Much more importantly, I am worryingly missing the big picture. Even if the org.slf4j.impl is exported according to our wishes, how is the org.slf4j package imported and by who? In other words, how does client code wishing to use the org.slf4j.Logger class get hold of it and what is the relationship between that client code and OSGi?
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 Let me know if this makes sense, Cheers, Hugues
Many thanks in advance for your response,
-- Ceki
ps. I am CCing dev@slf4j.org so that others can follow the discussion.
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
On Thu, Nov 26, 2009 at 10:08 AM, Ceki Gülcü <ceki@qos.ch> wrote:
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?
Ok the big picture is a lot more ambitous than the one I understood sorry! At a lower level I meant by OSGi container just the OSGi implementation: equinox, felix etc.
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.)
I need to think about this. It does feel that OSGi can do this type of thing quite well eventually. Hugues
_______________________________________________ slf4j-dev mailing list slf4j-dev@qos.ch http://qos.ch/mailman/listinfo/slf4j-dev
participants (2)
-
Ceki Gülcü -
Hugues Malphettes