Brendan,
The problem you describe is quite non-trivial but I really would like it
satisfactorily solved for log4j version 1.1. The latest code already in our CVS rep
allows the user to disable logging within a config file not just by calling
BasicConfigurator.disable(whatever). The disable/disableOverride code has been moved
to the Hierarchy class. It has been also cleaned up somewhat.
Here is a table of possible events, where "lib" is your library. "User first" means
that the user code accesses log4j (possibly configuring log4j) before the library. By
"lib first" I mean that your library gets initialized and accesses log4j before the
user's code.
------------+-------------+------------
| user not | user log4j
| log4j aware | aware
------------+-------------+------------
user first | N/A | case 1
------------+-------------+------------
lib first | case 2 | case 3
------------+-------------+------------
The desired behavior is:
Case 1: lib detects the user's log4j configuration and uses it without disrupting it.
Case 2: lib "disables" log4j in order to avoid the dreaded "No appenders" message.
Case 3: lib "disables" log4j but gets overridden when the user configures log4j.
The main point is that from the library's point of view, case 2 and 3 are
indistinguishable. Case 3, is interesting because unless the user takes explicit
overriding action, the "disable" call made by the library will well.. disable all
logging! Not what you want.
It follows that we need to introduce a weak form of disabling that will get
automatically overridden when the user configures log4j.
There are other solutions around this problem.
1) We could simply remove the "No appenders" message. This has been
discussed/suggested before. I think that it is important to give the new user some
active feedback when she forgets to initialize log4j.
2) The library adds a NullAppender to root category. This is really very easy to do
and should have negligible impact on performance but it's definitely a hack.
At 13:28 31.01.2001 -0500, you wrote:
>I'm using log4j in what is effectively a library -- code that is
>called from lots of places (different applications and jvms), some of
>which I don't write. I am using log4j in the library, and
>applications that I write properly configure log4j. However, I would
>like the library to be usable from code that is not log4j aware, and
>in particular not have the "No appenders could be found ... " message
>printed.
>
>I would like to be able to either:
>
>1) Turn off the printing of the no appender warning message for a
>particular category. This could easily be implemented by a method in
>Category that sets emittedNoAppenderWarning to true.
You probably don't want to bother.
>2) (Possibly a better solution) Disable all logging from the library
>by default, but enable logging if log4j is configured. This can, I
>believe, be accomplished by calling BasicConfigurator.disableAll() in
>a static initialization block in each library class. However, when
>the log4j system is configured, BasicConfigurator.overrideAsNeeded()
>must be called or the log4j.disableOverride property must be set. I
>would prefer to be able to only disable the Categories used in the
>library.
Right.
>It would be easier to solve this problem if one could determine if
>any configuration has been done, that is, if there are any Appenders
>attached to any Category. It seems like this would be very easy to
>keep track of by simply setting a boolean in the Hierarchy. Then, I
>would only call disableAll() in my libraries if no configuration had
>been done -- if configuration had been done, I would assume I am
>running in a log4j aware application, and that it will do appropriate
>configuration.
>
>I can think of several ways to solve this problem by extending
>Category or otherwise writing new code, but it seems like a common
>enough situation that there should be a way to do what I want with the
>standard distribution. What solutions am I missing?
Introducing weak disabling seems the most reasonable thing to do. Comments? Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
