Brendan McMahan 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.
>
> 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);
> }
> }
You can figure this out yourself by checking whether any Categories
other than the root exist *or* whether the root category has any
appenders. I sent this code snippet one or two days ago.
Alternatively (talking about hacks) you could tell your log4j aware
users that if they're going to configure your library they should always
set the priority of some bogus, unused Category to some well-defined
value, e.g. set
log4j.category.com.turbogenomics.mylib.use-log4j=EMERG
and your lib would test this priority and know that the app is taking
care of configuration.
Less ugly and much more starightforward they could also just be asked to
set a System property, e.g. -Dmylib.log4j=true, this can be done on the
cmd line or programmatically and in the former case avoids any issues
about whether your lib runs before or after the app.
>
> 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]
--
Anders Kristensen
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
