ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Goodin" <brandon.goo...@gmail.com>
Subject Re: Enabling Logging
Date Mon, 12 Jun 2006 12:25:28 GMT
Not completely. iBATIS is not in the business of being a logging
abstraction tool. All it is going to look for is the particular
logging system someone wants to use. If commons-logging is in the
classpath then the assumption is being made that a) it is being used
to delegate to another logging system or b) it is being used for
logging output (which it is actually capable of).

I really appreciate everyone's concern on this issue. But, I think
there has been enough speculative discussion on this matter. Jeff or I
will take a look at this today and try to either provide info on
proper logging configuration or a working example of the problem. Then
we can all take some action in one way or another and stop talking
about it ;-) If anyone would like to provide a working example for
themselves then it is certainly welcomed.

It would be appreciated if Ben or Tarek would place this into JIRA.


On 6/12/06, Tarek Nabil <Tarek.Nabil@tco.ae> wrote:
> But Jeff, isn't that how commons logging is used? If you have commons
> logging, you will probably also have log4j or some other implementation.
> Log4j/JDK 1.4 logging will be responsible for configuration and actually
> doing the logging, commons logging is just a layer above that.
>  ________________________________
>  From: Jeff Butler [mailto:jeffgbutler@gmail.com]
> Sent: Sunday, June 11, 2006 11:34 PM
> To: user-java@ibatis.apache.org
> Subject: Re: Enabling Logging
> It's also good to remember that iBATIS will use commons logging if it finds
> it in the classpath (for example, WebSphere has commons logging on the
> application server classpath QED iBATIS allways uses commons logging on
> WebSphere).
> The search order for log implementations is:
> 1. commons logging
> 2. log4j
> 3. JDK 1.4 logging
> iBATIS will use the first one it finds.
> Whenever there's a problem with iBATIS seeming to ignore the
> log4j.properties file I always think that iBATIS is trying to use commons
> logging instead.
> So look to see if commons logging is in the classpath somewhere - that's
> probably the problem.
> Jeff Butler
> On 6/11/06, Brandon Goodin <brandon.goodin@gmail.com> wrote:
> >
> We pulled out commons logging because we wanted zero dependencies and
> it was such an insignificant amount of code. It seemed silly to create
> dependencies for such a small amount of code. We are not going to add
> commons logging. But, we will fix our logging if it is not functioning
> :) If this is a common issue that folks are having then please submit
> a JIRA issue.
> Brandon
> On 6/11/06, Ben Munat <bent@munat.com> wrote:
> > Yeah it's a strange name/location but it should work... and Tarek claims
> to be getting
> > other log output to that file... and Tarek's question made me realize that
> I've never
> > actually been getting com.ibatis logging in my log files.
> >
> > So, I think there's a legitimate question here. Is there some trick to
> getting ibatis to
> > log? And, why does ibatis have it's own Log and LogFactory classes? Should
> these, if they
> > do cause problems, be switched to commons, juli, or sl4j?
> >
> > Clinton? Larry? Nathan? Anyone?
> >
> > b
> >
> > Graeme J Sweeney wrote:
> > > On Sun, 11 Jun 2006, Tarek Nabil wrote:
> > >
> > >> log4j.appender.RollingFile.File=c:/customs.log
> > >
> > >
> > > c:\customs.log ?
> > >
> >
> ********************************************DISCLAIMER********************************************
> This email and any files transmitted with it are confidential and contain
> privileged or copyright
> information. If you are not the intended recipient you must not copy,
> distribute or use this email
> or the information contained in it for any purpose other than to notify us
> of the receipt thereof.
> If you have received this message in error, please notify the sender
> immediately, and delete this
> email from your system.
> Please note that e-mails are susceptible to change.The sender shall not be
> liable for the improper
> or incomplete transmission of the information contained in this
> communication,nor for any delay in
> its receipt or damage to your system.The sender does not guarantee that this
> material is free from
> viruses or any other defects although due care has been taken to minimise
> the risk.
> **************************************************************************************************

View raw message