On Wed, 31 Jan 2001, Ceki Gülcü wrote:
> 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*.
Here is some pseudo-code that hopefully shows what i mean by category
level disabling:
class Category{
...
public
boolean isEnabledFor(Priority priority) {
if(disable >= priority.level) {
return false;
}else if( (this.weakDisabled && !hierarchy.hasBeenConfigured()){
return false;
}
return priority.isGreaterOrEqual(this.getChainedPriority());
}
}
The hierarchy.hasBeenConfigured() method would return true if any
appenders are attached to any Categories in the Hierarchy (it would just
check a boolean, set to true when an appender was added). IMHO, this
would be a useful function to have anyway. I would simply set
weakDisabled to true on the Categories in my library, so they would be
disabled until some configuration was done on the Hierarchy.
The advantage of this is that I don't have to touch the state of the whole
hierarchy. If I weakly disable the whole hierarchy and a user wants to
use log4j but doesn't configure it she won't get the warning message (at
least, this is how I was invisioning the semantics of weakly disabling the
whole hierarchy).
> 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.
The problem I see with this (and maybe I am missing something), is that if
she configures log4j from a configuration file in some main method, the
configuration will quite likely be done before the initialization of my
library classes. So when com.myCompany.myLib is instatntiated, it will
override the priority that the user wanted it to have. Now, if I had a
method in Hierarchy that let me determine if the Hierarchy had been
configured, I could do
static {
Category cat = Category.getInstance(MyLib);
if(!cat.getHierarchy().hasBeenConfigured()){
cat.setPriority(Priority.FATAL);
}
}
Minor confusion might arise if the user configured log4j after
MyLib was instantiated and assumed that no priority had been set for the
Category. I would of course document the above behavior, but users might
miss the point.
- Brendan
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
