Youch! Why the switch to LGPL for Logback? Yeah you're right we definitely
cannot use it :(. Also now with Logback what will happen to SLF4J? Rather I mean the other implementations of SLF4J? Just wondering what the support will be like now for SLF4J implementations. Alex On 3/20/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote:
Hi Emmanuel, I'd be happy to any questions you have about logback. Given that you are already using SLF4J, using logback as your underlying logging system should be extremely easy. Logback implements the SLF4J API natively. So, if you are using logback you have go through SLF4J. The inverse is obviously not true. So in your case, you have to declare logback as a dependency in the pom.xml file of your project and include a config file (logback.xml). However, since logback is licensed under LGPL, ASF's licensing policy will not allow Apache DS to depend on logback. So, I guess logback is not an option after all. Bummer. At 08:47 PM 3/20/2007, Emmanuel Lecharny wrote: >Thanks Ceki, > >when I read Justen's mail, I went to the logback site to see if it was an >option to migrate from what we use to this new lib. Sadly, I didn't had time >to dig seriously the pros and cons of doing it. > >We will need to think about it, as logback has evolved a lot since the last >time I checked it (end of last year ?). May be we will need to have a convo >with you about the advantage of migrating, and more important, the impact on >our code base and on our users. > >Atm, we are trying to cut two releases, but as soon as we are done, then we >will be able to reconsider the whole log problem. > >Thanks ! > >On 3/20/07, Ceki Gülcü <[EMAIL PROTECTED]> wrote: >> >> >>Hi Justen, >> >> > Avoid using 'odd' libraries like nlog4j, from what I can see after >> > trying to resolve these issues through Google, the API is not likely >> > to just spin it's wheels only having boutique integrations. The easier >> > something is to integrate the more likely it is to be used. A perfect >> > example of this is how unit test can be integrated with JUnit and I >> > will no longer need and external OpenLDAP server. >> >>I am sorry to hear that you are had trouble using nlog4j. Nlog4j has >>been superceded by logback, which like nlog4j, implements the SLF4J >>interface natively. Thus, it is very easy to switch from nlog4j >>(assuming you were using the SLF4J interface) to logback, log4j12 or >>JDK14 logging. >> >>Starting with SLF4J 1.3, depending on SLF4J means depending on >>slf4j-api without any implementation imposed on the end user. >> >>Here is a quote from the release notes: >> >> Release 1.3.0 consists of rearrangement of classes among >> projects. More specifically, the org.slf4j.LoggerFactory class is now >> packaged within the slf4j-api.jar file instead of the various slf4j >> bindings. It follows that client code needs to depend on only >> slf4j-api in order to compile, while the various slf4j bindings are >> only needed as runtime dependencies. See also the Maven2-related FAQ [1] >> entry. Given the practical significance of this change, we highly >> recommend that library-authors upgrade to version 1.3.0 at their >> earliest convenience. >> >>Thus, I would suggest that Apache DS upgrade to SLF4J 1.3.0 so as to >>offer more liberty and comfort to your end-users. >> >>I hope this helps, >> >>[1] http://www.slf4j.org/faq.html#maven2 >> >> >>-- Ceki Gülcü >>Logback: The reliable, generic, fast and flexible logging framework for >>Java. >>http://logback.qos.ch > > >-- >Cordialement, >Emmanuel Lécharny >www.iktek.com -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
