Hello all,
The question of markers have been previously debated on this list. I believe that markers will be a very significant feature of future logging systems but it's not easy to convince people of that when there are no logging systems taking advantage of markers. However, that will hopefully change after LOGBack is released to the wider public. You might be asking yourself why is the MakingLogger/Logger merge necessary or even appropriate? At present time, support for Marker objects may seem like unnecessary clutter. However, if and when users start taking advantage of markers, then the MarkingLogger/Logger separation would have caused a split between logging systems supporting markers and those that do not support them. I think it is undesirable to create two distinct logging worlds, those with and those without marker support. As the SLF4J API stands today, clients can easily switch between various logging systems. If logging systems supporting markers and those that do not have distinct SLF4J APIs (MarkingLogger vs. Logger), then SLF4J would obviously still allow switching within each logging world but not *between* those two worlds. You might suspect that the merge is a trick to force users to move to LOGBack (which supports markers). Actually, the exact opposite is true. The MarkingLogger/Logger merge will allow clients to switch *back* to log4j, jdk 1.4 logging or to x4juli even if they invoke marker specific logger operations in their code. As SLF4J of 1.0RC5, once a client decides to use markers, they cannot easily switch back to "older" logging systems, such as log4j or jdk 1.4 logging. The latest changes now SLF4J's SVN repository are designed to let clients to freely switch back and forth between logging systems regardless of marker support. Freedom of choice is what SLF4J is supposed to provide in the first place... Comments? -- Ceki Gülcü _______________________________________________ dev mailing list dev@slf4j.org http://slf4j.org/mailman/listinfo/dev
