On 16 Aug 2001 "Vincent Massol wrote:
> +0
>
> * I prefer to leave the choice of how to do logging or not to each
> component. What we should mandate, is that each component logging
> system need not impact on the logging system used by an end-user. In
> my opinion, users of a component would like to turn logs on sometimes
> to check what's going on but they won't want to mix these logs with
> their own logs (at least in most cases). The only issue I can see is
> each component will need to provide its own logging configuration and
> especially the output file path
> (which I set in Cactus to be the current directory).
As a testing framework, the case of Cactus is different because it is
probably not intended to be embedded in a larger application. A
general purpose library intended to be embeded in a larger application
(e.g. Digester) should not attempt to configure logging. It should let
the user configure log4j. If the user is interested in the log output
of Digester then the user can follow a well defined procedure to
enable Digester logging. This procedure can be part of Digester
documentation.
You can never totally predict how the user will want to configure
logging. This does not mean that there should not be an easy method
for enabling "default" logging in a given component but the initiative
of triggering it must be left to the end user.
> Question for Ceki: Is it possible to have several instances of Log4J (not a
> JVM singleton), so that it does not interfere with any other outside
> component. At the current time I use "PropertyConfigurator.configure(url);"
> which interferes.
I just wrote a short tutorial on this subject. You can download it from
http://jakarta.apache.org/~ceki/multHierarchy.tar.gz
This should also answer Costin's question regarding multiple hierarchy
configuration. (It's really not difficult nor tricky.)
Hope the tutorial on configuring log4j witj multiple hierarchies will
help. Regards, Ceki
ps: I am a member of this list. No need to cc: me.
