Ah we are using 1.5.8 currently. We should upgrade to 1.6 then.

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 >

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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)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(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev