[hibernate-dev] [infinispan-dev] Possible error of dependency on infinispan-query pom

[Ceki Gülcü]

On 14/07/2010 1:41 PM, Steve Ebersole wrote:
> Ah we are using 1.5.8 currently.  We should upgrade to 1.6 then.

Yes, you should upgrade to 1.6.0.

You should also be aware that slf4j-api 1.6. will *not* work with
bindings from the 1.5 series. So, if the next version of hibernate,
say 3.5.4 uses SLF4J version 1.6, when an end-user upgrades to
Hibernate 3.5.4, she will also need to update her SLF4J binding to
version 1.6 as well. For example, if the user has
slf4j-log4j-1.5.8.jar on the class path and upgrades to Hibernate
3.5.4, she will need to replace slf4j-log4j12-1.5.8.jar with
slf4j-log4j12-1.6.jar.

Now, if the user forgets to update the binding for log4j, then when
SLF4J initializes, the version mismatch issue will be *automatically*
detected and SLF4J will duly warn the user by emitting a message on
the console.

I would expect even a half-alert developer to successfully deal with
this issue within 10 minutes after upgrading. However, I have to admit
that some minimal amount of alertness of the part of the developer is
required. The upgrade process to SLF4J 1.6 is unfortunately not
totally transparent.

Note that the api and bindings in the 1.6 series are planned to be all
mutually compatible. The version mismatch issue only occurs when
upgrading SFL4J from the 1.5.x series to the 1.6.x series.

HTH,

> On Wed, 2010-07-14 at 13:24 +0200, Ceki Gülcü wrote:
>>
>> Galder Zamarreño wrote:
>>
>>   >  Hmmm, these looks like a problem in Hibernate Search since they're the
>>   >  ones using slf4j.
>>   >
>>   >  I don't see why Infinispan Query should explicitly declare a
>>   >  dependency on slf4j.
>>   >
>>
>> Hello Galder,
>>
>> The issue reported by Israel Lacerra, that is the NoClassDefFoundError
>> for org.slf4j.impl.StaticLoggerBinder, no longer occurs in SLF4J 1.6
>> and later. Upgrading to SLF4J v1.6 will cause the problem to
>> disappear.
>>
>> Quoting the SLF4J manual [1]:
>>
>>    Libraries
>>
>>    Authors of widely-distributed components and libraries may code
>>    against the SLF4J interface in order to avoid imposing an logging
>>    framework on the end-user of the component or library. He or she may
>>    choose the desired logging framework at deployment time by inserting
>>    the desired slf4j binding on the classpath, which may be changed later
>>    by replacing an existing binding with another on the class path and
>>    restarting the application. This approach has proven to be simple and
>>    very robust.
>>
>>    As of SLF4J version 1.6.0, if no binding is found on the class path,
>>    then slf4j-api will default to a no-operation implementation
>>    discarding all log requests. Thus, instead of throwing an exception,
>>    SLF4J will emit a single warning message about the absence of a
>>    binding and proceed to discard all log requests without further
>>    protest. For example, let Wombat be some biology-related framework
>>    depending on SLF4J for logging. In order to avoid imposing a logging
>>    framework on the end-user, Wombat's distribution includes
>>    slf4j-api.jar but no binding. Even in the absence of any SLF4J binding
>>    on the class path, Wombat's distribution will still work
>>    out-of-the-box, and without requiring the end-user to download a
>>    binding from SLF4J's web-site. Only when the end-user wishes to enable
>>    logging will she need to install a binding.
>>
>> I hope this sheds lights onto the  matter,
>>
>> --
>> Ceki
>>
>> [1] http://slf4j.org/manual.html#libraries
>>