Re: iBATIS3 and SLF4J

[Zart Colwin]

Clinton Begin wrote:
>> You think it's not a hack, I do think it is one,
You are rude, disrespectful and do not know what you're talking about.
Sorry for being rude and disrespectful, it was not my intention (my 
English vocabulary might be too limited to easily express myself with 
all the nuances required).

iBATIS isn't a logging framework, it USES and SUPPORTS various logging 
frameworks to make it as easy as possible for others to use it without 
dependencies.
Right, iBatis is not a logging framework so it probably shouldn't try to 
implements a logging facade, it better use an existing one.
I think I finally understand what your are saying with "without 
dependencies", but is it possible to achieve? iBatis will at least have 
a dependencies to a JDBC drivers isn't it, so why not having a 
dependency to a logging facade?  There are many frameworks that have 
such a dependency and it's not unacceptable.

  You might like SLF4J, but THOUSANDS of others might prefer log4j.
SLF4J is not a logging implementation, but a logging abstraction layer 
(i.e. a logging facade), it delegates to whatever implementation you put 
in the classpath: log4j, jdk1.4, simple, nop. It even can bridge to 
commons-logging.

Can we support SLF4J the same way?  Yes.  Can we make the logging 
framework pluggable and configurable?  Yes. 

Am I going to do it?  No. You are welcome to.
But we will end up with code that resemble what SLF4J have implemented. 
Better use SLF4J right from the beginning.

>> Chance are that SLF4J ***or*** commons-logging are already mandated 
by the client application itself

Yes "or"... OR... "or"!!!!  See, you don't get it.  You really don't 
understand the purpose of this implementation and you dare to 
criticize it in such a rude fashion.
Then why didn't you explained it when Mr Cyril P. asked why SLF4J was 
not used ?

Then stop.  You're wasting our time and making a fool of yourself.
You have the right to think that I'm making a fool of myself in 
defending the idea that SLF4J is a better solution to the logger 
alphabet-soup even for iBatis. I'm certainly not the best advocate but 
this probably doesn't gives you the right to attempt to unsubscribe me 
from the mailing list.

ZC.


Clinton




On Sat, Aug 29, 2009 at 4:28 PM, Zart Colwin <za...@wanadoo.fr 
<mailto:za...@wanadoo.fr>> wrote:

    It's not a hack, or at least no more than SLF4J was the first day
    they decided that they wanted something better than commons
    logging etc.

    => Have some respect for the opinions and efforts of others! <=
    I do respect efforts of others, that's why I wouldn't want to
    re-implement something that was already brilliantly implemented
    and documented, and amply tested by a large number of user. I
    wouldn't have the presumption to think that I could do better than
    Ceki Gülcü that have 10+ years of experience in that particular field.
    You think it's not a hack, I do think it is one, by examining the
    code for a few minutes I have found two "conceptual" bugs in it:
    - Q: How to express which Logging technology to bind to in case
    multiple are available from the classpath (a classical situation
    nowadays)? A: Basically you can't,  the lookup order is hard coded
    - first commons-logging, then log4j, then jdk4, etc...
    - Q: How to setup the classpath in order to use the
    "org.apache.ibatis.logging.nologging.NoLoggingImpl" ?  A: In fact
    you can't, since beginning with JDK1.4 java.util.logging.Logger
    will alway be present thus discovered by the lookup, thus iBatis
    will alway at least log through java.util.logging.Logger unless it
    runs on JDK1.3.
    Ho, and changing the client application code to call one of the
    LogFactory.useXxxLogging explicitly is not an option at deployment
    time.


    One of our goals has always been to have a single-jar deployment
    with no required dependencies -- a far cry from the JAR soup that
    many frameworks require.  
    Chance are that SLF4J or commons-logging are already mandated by
    the client application itself - I can hardly think of a modern
    application that doesn't log its own events. The JAR soup is
    "setup once and forget" kind of problem just setup your ant script
    or maven pom and forget about it. Not big enough to warrant the
    rewrite of an existing library.


    We don't want to create version dependency conflicts with other
    open source projects.
    What version dependency conflicts? SLF4J is an interface, backward
    compatibility is taking very seriously by the SL4FJ team and is
    guarantied for simple logging usage.


    The problem with logging was created by Sun years ago, and now we
    have to deal with it.
    Because Sun snub the excellent Log4J. Does Sun have come with
    something better than Log4J ? Hardly so. SLF4J was created
    especially to deal with the issue created by stupid Sun;  Not
    using it is counter productive (even insulting for whom have
    created it).


    If you want to implement  SLF4J and contribute it, then do so and
    attach it to a JIRA ticket.  Here's the interface:

    
http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/ibatis-3-core/src/main/java/org/apache/ibatis/logging/
    I'd rather prefer to fix iBatis so that it uses SLF4J directly and
    then let SLF4J community implements new binding if/when one need.


    sincerely, I hate to argument that way, but I sincerely think that
    collaboration between open source projects is better than
    isolation and I still can't see a good reason why SLF4J couldn't
    be used to begin with.

    sincerely,
    ZC.




    Clinton Begin wrote:
    It's not a hack, or at least no more than SLF4J was the first day
    they decided that they wanted something better than commons
    logging etc.

    => Have some respect for the opinions and efforts of others! <=

    One of our goals has always been to have a single-jar deployment
    with no required dependencies -- a far cry from the JAR soup that
    many frameworks require.  We don't want to create version
    dependency conflicts with other open source projects.

    The problem with logging was created by Sun years ago, and now we
    have to deal with it.  iBATIS can use Commons Logging (and thus
    whatever it supports), Log4J or Java 1.4+ Logging directly.

    The dependency on Log4J was accidental (a bug).  iBATIS *DOES
    NOT* depend on Log4J.  The issue is fixed, as per this JIRA ticket:

    http://issues.apache.org/jira/browse/IBATIS-626

    If you want to implement  SLF4J and contribute it, then do so and
    attach it to a JIRA ticket.  Here's the interface:

    
http://svn.apache.org/repos/asf/ibatis/java/ibatis-3/trunk/ibatis-3-core/src/main/java/org/apache/ibatis/logging/

    Cheers,
    Clinton

    On Sat, Aug 29, 2009 at 7:30 AM, Zart Colwin <za...@wanadoo.fr
    <mailto:za...@wanadoo.fr>> wrote:


        I'm not convinced that slf4j is any better than the more
        widely used commons-logging. 
        Market share or product market penetration often do not
        directly reflect the quality of one product compared to
        another one. It merely reflect the power of one supplier to
        impose its products over the other ones; It is not unexpected
        to see commons-logging still having more market penetration
        than SLF4J since commons-logging was there earlier and since
        many ASF framework largely use it.

        Taking your words literally, then no-one should bother to use
        iBatis since the market ORM/persistance is largely dominated
        by Hibernate which have a huge advance in market share over
        any other ORM/persistance frameworks. The same goes true for
        things like Firefox against IE, Linux against Window, even
        Windows7 against WindowsXP.


        If we want logging autonomy I'd rather go with what we did
        in the last version and simply implement an internal
        commons-logging-ish solution.
        I'm completely shocked that you did this. What was so wrong
        with SLF4J or commons-logging that you decided to hack your
        own logging abstraction layer?   Standing by your own
        statement, how can you be convinced that your hack is any
        better than the more widely used SLF4J or commons-logging?


        ZC


        Brandon Goodin wrote:
        I'm not convinced that slf4j is any better than the more
        widely used commons-logging. I know there are those who
        believe passionately on both sides of this discussion and I
        don't mean to berate anyone. If we want logging autonomy I'd
        rather go with what we did in the last version and simply
        implement an internal commons-logging-ish solution.

        Brandon


        On Tue, Aug 18, 2009 at 11:22 AM, Cyril Pfaff
        <cyril.pf...@gmail.com <mailto:cyril.pf...@gmail.com>> wrote:


            Hi, 

            Thanks for this amazing product.



            Currently, iBATIS3 currently depends on log4j. Even if I
            like log4j, It would be interesting to look at SLF4J
            (http://www.slf4j.org/) as it may offers more
            flexibility (Basically due to the fact that it's an
            abstraction layer for various logging frameworks.)


            I did not find anything interesting in the mail archive
            regarding this subject:

            So ... what about slf4j ? Has this option already been
            discussed and rejected internally, or is it possible to
            use this logging facility instead of log4j in the next
            releases of iBATIS3 ??

            Thanks again for your time.
            Regards.
            c.