http://bugzilla.slf4j.org/show_bug.cgi?id=236 JY Cronier <cronier.jy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cronier.jy@gmail.com -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=236 Thorsten <thorsten.Moeller@unibas.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |thorsten.Moeller@unibas.ch --- Comment #2 from Thorsten <thorsten.Moeller@unibas.ch> 2011-09-01 12:54:38 CEST --- Keep in mind that java.util.ServiceLoader exists since Java 6. It used to be in an internal package (com.sun?) before. Backwards compatibility is still an issue (knowing that Java 1.4, 1.5 reached end of life)? -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=236 --- Comment #4 from Thorsten <thorsten.Moeller@unibas.ch> 2011-09-05 11:32:27 CEST --- (In reply to comment #3)

Disadvantages of ServiceLoader

3) ServiceLoader mechanism is actually more complex than the stupid static mechanism we currently have. Static binding is as stupid as it gets. It is therefore easy to understand for those willing to spend one or two mental cpu-cycles

Something that you also might want to keep in mind is that static binding as it is currently implemented by SLF4J is "not compatible" with the Android platform. Well, not totally incompatible but inducing the need to deviate from the way SLF4J is used in Java standard edition. The point is that Andoid's model implies that static bindings are resolved at build time of an application rather than at deployment time. More precisely, build time here means not compile time (which is part of build time) but postprocessing time as done by the Dexer (which takes compiled bytecode and optimizes it; afterwards dex code will be assembled into Android-specific application packages). Simply providing the slf4j-api.jar and the jar file(s) of the logging binding that one wishes to use (e.g., logback-*.jar) to the Dexer -- which is what an "uninformed" developer would intuitively do -- does not work. There are, however, ways to resolve this issue. One way is to create log-backend-specific "all-in-one" jars that contain SLF4J's API part minus the dummy implementation(!) and the logger binding implementation. This is what is essentially done by the SLF4J-Android project. However, this approach is actually on top of the approach where one would completely build from sources (i.e., applications include the source of the SLF4J API part and the logging backend they wish to use). The downside is that they both require To conclude, a mechanism such as the META-INF/services one used by ServiceLoader (and I suppose that OSGi mechanisms are conceptually the same) would simplify and solve this issue, which is why I would opt for a more dynamic binding mechanism. Anyway, the question is also whether having the Android platform on board is actually considered important. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=236 --- Comment #6 from Thorsten <thorsten.Moeller@unibas.ch> 2011-09-05 12:19:13 CEST --- (In reply to comment #5)

Thorsten, in comment #4, second paragraph, you have an incomplete sentence: "The downside is that they both require"

Uups, it's an artifact. What I wanted to state there is that, from the developer's perspective, both approaches require to deviate from the standard way SLF4J is used, which is not intuitive for people that have the standard SLF4J usage mindset and therefore needs to be well explained. It would be better to have a consistent usage model among all platforms. -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

http://bugzilla.slf4j.org/show_bug.cgi?id=236 Simon Chemouil <schemouil+slf4j@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |schemouil+slf4j@gmail.com --- Comment #11 from Simon Chemouil <schemouil+slf4j@gmail.com> 2012-10-18 10:21:24 CEST --- (In reply to comment #10)

For OSGi experts : What would be the best thing to do to instantiate the right implementation?

From an OSGi standpoint, j.u.ServiceLoader can work jumping through hoops as Philippe described (there is an implementation of such a bridge at Apache Aries [1]).

The current one seems not be the best one: http://informatics-science.blogspot.fr/2012/10/osgi-friendly-apis.html

Using j.u.ServiceLoader won't solve the problem described here, even though it could improve the situation as it is more general than what slf4j's static binding currently does, and could more easily be ignored. The proposal linked in my blog is to provide a lighter version of slfj4-api that doesn't know about binding at all. It could help adopting ServiceLoaders, because it would be up to anyone to choose the binding their prefer. In general, this slf4j-api-light artifact could make the life easier for slf4j on Android, OSGi and those who'd rather declare implementations using ServiceLoaders. [1] http://aries.apache.org/modules/spi-fly.html -- Configure bugmail: http://bugzilla.slf4j.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.