ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zart Colwin <za...@wanadoo.fr>
Subject Re: iBATIS3 and SLF4J
Date Sat, 29 Aug 2009 22:28:04 GMT
> 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 <zartc@wanadoo.fr 
> <mailto:zartc@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.pfaff@gmail.com <mailto:cyril.pfaff@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. 
>>
>>
>

Mime
View raw message