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

Steve Ebersole steve at hibernate.org
Wed Jul 14 10:13:00 EDT 2010


and http://opensource.atlassian.com/projects/hibernate/browse/HHH-5382
(linked)

On Wed, 2010-07-14 at 14:56 +0100, Emmanuel Bernard wrote:
> 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> 
> 
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

-- 
Steve Ebersole <steve at hibernate.org>
http://hibernate.org




More information about the hibernate-dev mailing list