http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-559
On 14 juil. 2010, at 14:45, Galder Zamarreño wrote: > Emmanuel, > > I've created https://jira.jboss.org/browse/ISPN-541 to revisit current query > module dependencies when Hibernate Search upgrades to SLF4J 1.6. > > If you create a jira for that, let me know so that I can keep track of it and > find out when an updated HBS is released. > > Cheers, > > On Jul 14, 2010, at 2:23 PM, Ceki Gülcü wrote: > >> 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 >>>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
