At 17:21 31.01.2001 -0500, you wrote:
>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.
OK I'm convinced. There will be a Hierarchy.hasBeenConfigured() in the next version.
(This feature has been requested a number of times recently.)
>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).
Sorry, I don't see the point especially after reading your next solution quoted below.
>> 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);
> }
> }
Absolutely. Hence the requirement for hasBeenConfigured.
>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.
You can tell them that if they want to see logging output from your library then they
should *always* set "com.myCompany.MyLib" to INHERITED or to an appropriate Priority.
This is beginning to take shape. Ceki
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
