[slf4j-user] Java 5 version of SLF4J?

[Ceki Gulcu]

Hi Joern,

Christopher White's sums the warts in the SLF4J API pretty well:

   I did know that I can parameterize up to 2 parameters, which is
   nice. But I also think that it is annoying to have to remember to
   change the syntax once you hit 3+ parameters. Along with this, it is
   also annoying to have to remember to change syntax when logging errors
   (cannot use paramatized strings). It would be nice if things were more
   consistent.

Your patch for bug 31 is pretty nice and is probably the best that can
be done under the circumstances. However, it would force our users to
*think* about what the implications of using slf4j-api-jdk15.
Developers are sick and tired of dealing with logging related issues
in their projects. For example, a few months ago the Apache Directory
project had an animated debate on why logging was so darn
complicated. Such debates occur frequently in various mailing lists.

One of the reasons SLF4J exists, is to make life easier for
developers. It would not be wise to introduce a new level of
complexity on account of two near-equivalent SLF4J-API artifacts.

Simon could probably attest that as far logging is concerned, even the
slightest complexity takes on frightening proportions.

Joern Huxhorn wrote:
> Hi guys.
> 
> My patch available at http://bugzilla.slf4j.org/show_bug.cgi?id=31 
> supports varargs without changing the slf4j API at all.
> 
> It would be included in maven like this
> 
> <dependency>
>          <groupId>org.slf4j</groupId>
>          <artifactId>slf4j-api-jdk15</artifactId>
>          <version>1.5.0</version>
>          <scope>compile</scope>
>          <!--
>          replacement for slf4j-api below
>          -->
> </dependency>
> <dependency>
>          <groupId>org.slf4j</groupId>
>          <artifactId>slf4j-api</artifactId>
>          <version>1.5.0</version>
>          <scope>provided</scope>
>          <!--
>          overrides transitive dependencies,
>          replaced by slf4j-api-jdk15 above
>          -->
> </dependency>
> 
> It is possible that
> <dependency>
> 	<groupId>org.slf4j</groupId>
> 	<artifactId>slf4j-api-jdk15</artifactId>
> 	<version>1.5.0</version>
> 	<scope>compile</scope>
> 	<exclusions>
> 		<exclusion>
> 			<groupId>org.slf4j</groupId>
> 			<artifactId>slf4j-api</artifactId>
> 		</exclusion>
> 	</exclusions>
> </dependency>
> would work, too, but I never tried that...
> 
> slf4j-api-jdk15 is an *additional* artifact that contains the slf4j API 
> using varargs instead of Object[].
> 
> That's why slf4j-api is *not* changed/polluted at all!
> 
> Modules/libraries compiled against slf4j-api will just work with 
> slf4j-api-jdk15.
> 
> Obviously, the opposite is not the case:
> 
> Modules/libraries compiled against slf4j-api-jdk15 will require 
> slf4j-api-jdk15 and can not be switched back to slf4j-api because they 
> use jdk15 specific code.
> I can't see *any* problem with this fact since, well, they are jdk15 
> dependent - otherwise they couldn't (slf4j-api-jdk15 *requires* jdk15) 
> and wouldn't (you don't *have* to use slf4j-api-jdk15 if you use 
> jdk15... you can still use slf4j-api if you don't care about varargs) 
> use slf4j-api-jdk15.
> 
> Greetings,
> Joern.


-- 
Ceki Gülcü
QOS.ch is looking to hire talented developers in Switzerland.  If
interested, please contact c e k i AT q o s . c h