[slf4j-dev] SL4FJ light: ad-hoc bindings for friendlier OSGi/IoC integration

[Simon Chemouil]

On Wed, Oct 17, 2012 at 9:53 AM, Gunnar Wagenknecht
<gunnar at wagenknecht.org> wrote:
> After reading through the proposal I was wondering if adding a setter to
> LoggerFactory (note: over-simplified!) has been considered an option?
> In combination with an activator for the SLF4J API this might be a
> flexible and simple way to open the gate for a broad range of other
> options without causing too much disruption in the user base.

Hi Gunnar,

First thank you for your message and proof-of-concept.

I considered this option before submitting my proposal, but I found it
to be "un-OSGi", since this way static clients of the LoggerFactory
can access ILoggerFactory services without binding them using their
own bundle context, and thus circumvent optional security or service
filters (as in OSGi subsystems). Your proposal does fix the import on
org.slf4j.impl by making it optional, but because of the fact that the
call to getLogger() is static, some class may get a no-op logger
*before* any ILoggerFactory service is registered: so a proxy is
needed not only for swapping implementations, but simply to benefit
from dynamic installation order.

I am also worried that this technique will make the behavior of
slf4j-api differ between OSGi and non-OSGi environments (with a
different binding system used implicitly) and might confuse more than
it helps.

I do find your solution useful for OSGi users who don't care about
permisions/service hooks and need backwards compatibility with static
LoggerFactory but need the dynamic OSGi binding, but I would make it
something complementary to solution (3) rather than the solution on
its own. I personally would rather have the API be just that: a
passive API that doesn't register service listeners or tries to find
an implementation.

> Moving Logger and LoggerFactory out of "org.slf4j" just for the sake of
> OSGi (or any other runtime environment) does not sound like the best
> option to me. It causes migration grief for many, many users to satisfy
> a (IMHO) much smaller group of SLF4J implementors/integrators.

The proposal I am pushing for (solution 3) would not change org.slf4j
and we would keep LoggerFactory there. However we would introduce a
new package, org.slf4j.api, with only the interfaces. The plan is to
make it entirely transparent for all existing users (both OSGi and
non-OSGi). There would be 4 deprecated interfaces but:
* they would remain in the official distribution for a long time
* it would still be possible after their removal to provide a simple
compat JAR for non-OSGi users (and OSGi users using Require-Bundle to
force split package resolution)
* their replacement would be their exact copy, the fix is a matter of
changing an import. We can upgrade the migrator tool to also support
this.

I honestly do feel like there is no reason for grief, because there is
no migration. The JAR you use (slf4j-api), either downloading or from
Maven central, will have the same contents for years. Two new JARs
will be introduced for those of us who explicitly want less.

> I think Ceki can provide more details of the effects this might cause.
> For example, the method (in it's current implementation) allows changing
> the factory at runtime multiple times. For this to work reliable, the
> Loggers really need to become proxies to the actual ("current") logger.
> They are usually held in static variables. A really dynamic OSGi
> implementation might actually implement it that way. However, SLF4J can
> simply delegate that complexity to the runtime.

As I mentioned earlier, we discussed using proxies for loggers. My
understanding is that SLF4J would need to define an extension so that
the delegates doing the messy work can declare themselves. I feel this
increases complexity for little benefit.


Cheers,

-- 
Simon