Why don't we write a static initializer that checks to see if the log4j
configuration was loaded from a file or not, and adjusts the root
logging level accordingly? It's a bit of a hack, but neither releasing
with default DEBUG nor releasing with a default log4j.properties file is
a great option, and there is no real way to know which is worse.
Ultimately I think this is one of many good reasons that we should be
using our own logging facade instead of directly calling into
slf4j/log4j throughout the code. If we had our own facade there would be
a single point of control where we could detect whether the logging
system underneath us was initialized or not and choose what to log in
that situation.
--Rafael
Martin Ritchie wrote:
2009/10/26 Rajith Attapattu <[email protected]>:
Hi Martin,
I noticed that the log4j.xml in the client module had been deleted in rev 828019
I didn't see anything in the commit log for that revision, so I assume
it was a mistake.
It was, thanks for reminding me though, it is now back at r830102. As
I said in my earlier email I have huge reservations about the
inclusion of this file. We should at most be including an example
configuration file along with documentation of how to use it. The JAR
should not have any file that will automatically be picked up by
log4j, i.e log4j.xml or log4j.properties.
Anyways once that is removed we are now back to square one.
We *cannot* release the java client with debug logging enabled as it
introduces a massive performance drop.
I would actually go the other way and say we *cannot* release *with*
this file. Leaving our users log4j configuration up to the vagaries of
classpath is not acceptable IMHO.
Try starting the java broker without the org.apache.commons setting to
WARN. It logs at debug by default.
Checkout the activemq release there is no log4j.[xml|propertiy] files
in their release.
I would bet that ALL library jars released from Apache have no log4j.*
files contained within them.
If a user is writing a performance test they should really be giving
their logging some consideration and not just using a default value.
I library class such as our qpid-client should not be making any
assumptions about how our users what their logging set up. If they
don't take the time to configure logging then the performance may well
be terrible. As an example take a look at the commons package. We
started using that in the Java broker for XML parsing and until we set
it back to WARN in our log4j config it more than doubled the standard
broker startup logging.
We need to make things work as best as possible out of the box.
First impressions count and we don't want to loose potential users
bcos they ran their tests while debugging was enabled.
I agree that things need to work out the box and they do currently. If
we start adding default log4j config then we may end up breaking users
configuration and making it very difficult to find out why.
Most users do not expect debug logging to be enabled by default.
You only turn debug on when you need to debug an issue.
I would again agree here, but I would argue that this user is not the
same as the developer above. Developers need t be aware of the
implications of using a library. If actually we shipped a useful
client README file that explained how to configure usable logging then
things would be better. INFO/DEBUG is not a useful distinction IMHO,
INFO doesn't have enough, DEBUG is to chatty. Sometimes you want to
just have status messages about new model objects rather than logging
every byte of every frame.
Martin
Regards,
Rajith Attapattu
Red Hat
http://rajith.2rlabs.com/
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
---------------------------------------------------------------------
Apache Qpid - AMQP Messaging Implementation
Project: http://qpid.apache.org
Use/Interact: mailto:[email protected]
