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.
