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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 ?
> >
>
