You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Cyril Pfaff <cy...@gmail.com> on 2009/08/18 18:22:37 UTC
iBATIS3 and SLF4J
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.
Re: iBATIS3 and SLF4J
Posted by Zart Colwin <za...@wanadoo.fr>.
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 <zartc@wanadoo.fr
> <ma...@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 <zartc@wanadoo.fr
>> <ma...@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 <ma...@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.
>>>
>>>
>>
>
Re: iBATIS3 and SLF4J
Posted by Clinton Begin <cl...@gmail.com>.
For anyone curious about the history, and just to defend against the
ridiculous accusation of "not invented here syndrome", we did depend on
commons-logging over 5 years ago...
http://ibatisdb.cvs.sourceforge.net/viewvc/ibatisdb/ibatis-dbl-2/src/com/ibatis/common/jdbc/logging/ResultSetLogProxy.java?revision=1.1&view=markup
However, we had a lot of people with differing opinions:
* Log4J users were annoyed that they had to configure commons logging
* Commons logging users wouldn't be happy with just log4j
* JDK 1.4 released around that time with its own logging solution
* Various other frameworks chose either log4j or commons-logging, and if you
chose to use both iBATIS and another framework, it was very annoying if they
used two different logging frameworks. It was even more annoying if they
used two different aggregates (e.g. say iBATIS used SLF4J and Stripes used
Commons Logging... that would be pretty annoying).
So the iBATIS solution was to do its best to detect what you were using, and
use that, starting from the most abstract (commons logging) and working its
way down to the lowest common denominator (JDK 1.4), with intelligent
defaults for the most popular (log4j).
Comments and feedback are welcome (similar to Cyril's original post, which
started a healthy, interesting discussion).
Cyril, I'm sorry your thread was hijacked.
Clinton
On Sat, Aug 29, 2009 at 5:51 PM, Clinton Begin <cl...@gmail.com>wrote:
> >> that was already brilliantly implemented and documented, and amply
> tested by a large number of user.
>
> The iBATIS logging implementation predates SLF4J by about 3 years, and has
> been tested by thousands of users.
>
> >> 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.
> 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. You might like SLF4J, but THOUSANDS of others might prefer
> log4j.
>
> 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.
>
> >> 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.
>
> >> Not using it is counter productive (even insulting for whom have created
> it).
>
> iBATIS beat them to it. They should use ours. Am I insulted they didn't?
> No. I've never even heard of them.
>
> >> sincerely, I hate to argument that way,
>
> Then stop. You're wasting our time and making a fool of yourself.
>
> Clinton
>
>
>
>
>
> On Sat, Aug 29, 2009 at 4:28 PM, Zart Colwin <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> 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 <cy...@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.
>>>
>>>
>>>
>>
>
Re: iBATIS3 and SLF4J
Posted by Clinton Begin <cl...@gmail.com>.
>> that was already brilliantly implemented and documented, and amply tested
by a large number of user.
The iBATIS logging implementation predates SLF4J by about 3 years, and has
been tested by thousands of users.
>> 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.
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. You might like SLF4J, but THOUSANDS of others might prefer
log4j.
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.
>> 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.
>> Not using it is counter productive (even insulting for whom have created
it).
iBATIS beat them to it. They should use ours. Am I insulted they didn't?
No. I've never even heard of them.
>> sincerely, I hate to argument that way,
Then stop. You're wasting our time and making a fool of yourself.
Clinton
On Sat, Aug 29, 2009 at 4:28 PM, Zart Colwin <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> 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 <cy...@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.
>>
>>
>>
>
Re: iBATIS3 and SLF4J
Posted by Zart Colwin <za...@wanadoo.fr>.
> 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
> <ma...@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 <ma...@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.
>>
>>
>
Re: iBATIS3 and SLF4J
Posted by Clinton Begin <cl...@gmail.com>.
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> 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 <cy...@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.
>
>
>
Re: iBATIS3 and SLF4J
Posted by Zart Colwin <za...@wanadoo.fr>.
> 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
> <ma...@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.
>
>
Re: iBATIS3 and SLF4J
Posted by Brandon Goodin <br...@gmail.com>.
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 <cy...@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.