Brendan,
I was of course referring to global (or hierarchy-wide) disabling. Global disabling is
a simple but very important feature. All printing methods (e.g. debug, info, etc.)
first check if log4j is disabled for the relevant *priority* (regardless od category)
and if so exit immediately. This check involves an integer comparison which is very
quick.
If the first check succeeds then there is a comparison between the priority of the
category and the priority of the call. This checks may involve a hierarchy walk which
is a few orders of magnitude slower than integer comparison (depending on the length
of the walk).
At 15:50 31.01.2001 -0500, you wrote:
>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.
I don't see what a second form of disabling at the category level would bring. I can't
even imagine what it would *mean*.
By the way, if your library resides in a package of its own, say com.myCompany.MyLib,
then all you have to is to set com.myCompany.MyLib to some very high priority like
FATAL. This should work without any need to mess with BasicConfigurator.disableAll().
There is no need to introduce weak disabling either.
You would write:
package com.myCompany;
public class MyLib {
static {
Category.getInstance(MyLib).setPriority(Priority.FATAL);
}
// rest of MyLib
}
If the user is log4j aware, and she is also interested in log output generated by
MyLib, then she can set the priority of the "com.myCompany.MyLib" category to the
value of verbosity she desires.
Hey, look! No hands, no weak disabling. :-)
>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.
Exactly. But as discussed above no new code is necessary. Would you concur? Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
