Hello Hugues,
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. 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. 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? Many thanks in advance for your response, -- Ceki ps. I am CCing dev@slf4j.org so that others can follow the discussion. _______________________________________________ dev mailing list dev@slf4j.org http://www.slf4j.org/mailman/listinfo/dev
