Thanks for the quick reply, Ceki.
I agree that some form of weak disabling is the best solution. Questions
that come to mind are:
Is weak disabling best done on a per-category or per-hierarchy basis? My
first response is to say that it makes the most sense on a per-category
basis, so for example I would only weak-disable the categories in my
libraries. This would certainly give the most flexibility. On the other
hand, it would also mean adding more methods to Category class, which
already bosts quite a few methods.
One thought on this, as something of a side note: What about providing an
AdvancedCategory that extends Category and contains less frequently used
methods -- stuff that is not necessary for every Category, but would be
useful in enough cases to be worthy of inclusion in log4j. Weak disabling
would be one example, and I can think of others. This might be a nice way
to provide some extra features without requiring new users to sort through
tons of methods to find the important ones.
Back to the issue at hand: Having weak-disabling on a per-hierarchy basis
would more closely parallel the current disabling mechanism, and would
probably only require the addition of one or two methods to the Hierarchy
class.
Adding weak disabling in any form would add a another level of complexity
to the system because there would be three mechanisms that control wether
a logging event is enabled or disabled: 1) priority 2) weak-disabling and
3) "strong" disabling. It would be nice if, at least from the users point
of view, the two forms of disabling could be rolled together into a
uniform framework. I haven't thought through a way to accomplish this,
though.
- Brendan
A couple more comments below:
On Wed, 31 Jan 2001, Ceki Gülcü wrote:
>
> 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.
Exactly, thanks for clarifying this point. I should have included
something along the lines of your table in my original message. I was
basically ignoring case 3, or at least assuming that if the user code was
log4j aware that the user would know to take explicit overriding action.
But this isn't necessarily a good assumption.
> It follows that we need to introduce a weak form of disabling that
> will get automatically overridden when the user configures log4j.
Right.
> 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.
I agree, I think the warning is important in most cases.
> 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.
I hadn't thought of this, I will probably use this solution for now.
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
