On Wed, Oct 17, 2012 at 9:53 AM, Gunnar Wagenknecht <gunnar@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