Log4J + Torque ... gonna drive me mad.

(for i in `find . -name '*.jar'`; do echo $i; unzip -t $i | grep
.properties; done) /properties.txt
>
>
More fun, on compliant Unix systems : find . -name '*.jar' -exec unzip -t {}
| grep .properties \;

Anyway
I did as David Beukes said.
I put a commons-logging.properties file on my classpath, and deported log4j
conf on log4j.properties.
I know have log working but not really.
I get DEBUG entries on the log, then suddenly, the same error as before on
System.err, but with different class target :

"log4j:WARN No appenders could be found for logger
().
log4j:WARN Please initialize the log4j system properly."

I don't even understand why it is talking about "org.apache.commons" AS I
SPECIFICALLY TLD that I wanted to log org.apache.torque only do you
think this is about another log4j file somewhere in my classpath ? (I run
tests on Windows now, so I can't script a find :p).

Here is the commons-logging.properties:



Here is the log4j.properties:
= ALL, org.apache.torque
=
= log/data.log
= org.apache.log4j.PatternLayout
= %d [%t] %-5p %c
- %m%n
= 5
= 1MB
= true

By the way, these 2 files are in my project root /conf directory, which is
explicitely added on classpath.

Thanks in advance once again.

--
Pierre.
Some people, when confronted with a problem, think "I know, I'll use XML".
Now they have two problems. -- Jamie Zawinski / James Robertson

I just added this to log4j.properties :

log4j.category.rootCategory = ALL, org.apache.torque
= ALL, org.apache.torque

THIS IS WRKING !

But it still think that's a Torque/commons-logging bug, whih is not
correctly handling Log4j config.

I have a different opinion about this. Torque does neither initialize
log4j nor commons-logging. It is up to the user to do this. If you don't
initialize logging, the standard configuration is used. This is the
intended behaviour.

Unfortunately for you, the standard configuration for commons-logging is
to use log4j if it is in the classpath, and the standard configuration for
log4j is to complain if it is not initialized. There is nothing Torque can
do about this.

I'm not an expert in log4j, but it seems that if you can add something to
your log4j.properties which makes log4j work as you want to, then the
previous log4j was wrong, and now you got it right.

Thomas

Hi everyone !

By the way thank you very much everyone involved for clarifying this so
much.


Thanks you very much as well, this have been really helpful considering the
lack of examples for this situation on the Web.



>
I have a different opinion about this. Torque does neither initialize
log4j nor commons-logging. It is up to the user to do this. If you don't
initialize logging, the standard configuration is used. This is the
intended behaviour.
>

I agree with that.
But as it's Torque (or commons-logging) which UTPUT the log messages on the
classes and packages it wants, it should ensure that something could be done
with the Log4j configuration, or guess, or whatever, or at least the Torque
website should have a FAQ which says that this package and this package MUST
have appenders configured, because we're not supposed to know who outputs !!

Then, to conclude, T HAVE TRQUE LG WRKING :

- Just put a log4j.properties in your classpath, saying that :
log4j.category.rootCategory = <whatever>
= <whatever>
= <whatever>
<rest of config files>

- Put a commons-logging.properties in your classpath with these 2 lines :



You need commons-logging and log4j jars (and probably other dependencies) to
make this working, of course.

That's it !
Thanks again everyone !


--
Pierre.
With some more efforts, maybe one day Human beings could win against library
configuration :p

I agree with that.
But as it's Torque (or commons-logging) which UTPUT the log messages on
the
classes and packages it wants, it should ensure that something could be
done
with the Log4j configuration, or guess, or whatever, or at least the
Torque
website should have a FAQ which says that this package and this package
MUST
have appenders configured, because we're not supposed to know who
outputs !!

I agree it should be documented what to do. But I still am convinced that
no library should attempt to configure the logger. Imagine you have some
twenty libraries and each does some initialisation by guess a
nightmare.

Then, to conclude, T HAVE TRQUE LG WRKING :

- Just put a log4j.properties in your classpath, saying that :
log4j.category.rootCategory = <whatever>
= <whatever>
= <whatever>
<rest of config files>

- Put a commons-logging.properties in your classpath with these 2 lines
:





You need commons-logging and log4j jars (and probably other
dependencies) to
make this working, of course.

Thanks a lot, I'll ad that to the documentation.

Thomas