Re: Changing categories for long-running processes...

[ja...@cardsetc.com]

> It seems like you may be asking, "Can I change a config file
> and have log4j change along with it, without having to restart the
> app?"  You can also do this. Check out the configAndWatch method on the
> configurator class.

But will those changes affect Category instances that have already been
obtained by a class?

For example, assume I have an instance of some class (say
somepackage.SomeClass) that lives for the life of the application (possibly
a singleton instance). When it is instantiated it obtains a Category, but
at that point in time there is no Category in the hierarchy specifically
for instances of somepackage.SomeClass, therefore it receives the root
Categeory; lets say that Category ignores all messages of TRACE priority.
At some later point, the administrator sees some fishy behaviour in the
system, and suspects somepackage.SomeClass to be responsible. Therefore she
wants to turn on the tracing for somepackage.SomeClass, but not without
having to shut the system down and deny service to the users (the unusual
behaviour is not critical at this point). So she updates the configuration
of the logging subsystem to include a Category for somepackage.SomeClass,
picking up the TRACE priority messages and dumps them into a logfile.
However, the instance of somepackage.SomeClass has already obtained its
Category instance.

I'd rather have the somepackage.SomeClass instance call
Category.getInstance() only once, for performance reasons (calling it at
the beginning of every method would be a significant overhead yes?) - but I
don't want to sacrifice the ability to change the hierarchy without having
to shutdown the application. Perhaps this is just one of those tradeoffs
you have to make, but perhaps if category instances are NOT shared between
other object instances, then it would be possible for the Log4J
Configurator object to send a message to each Category instance out there,
to reflect the Category hierarchy. If this is not the way things are,
perhaps it can be done via the Log4J SPI?

Regards,
James W.


---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org

Re: Changing categories for long-running processes...

[Paul Glezen <pg...@atdial.net>]

james.webster@cardsetc.com wrote:
> 
> > It seems like you may be asking, "Can I change a config file
> > and have log4j change along with it, without having to restart the
> > app?"  You can also do this. Check out the configAndWatch method on the
> > configurator class.
> 
> But will those changes affect Category instances that have already been
> obtained by a class?
> 
> For example, assume I have an instance of some class (say
> somepackage.SomeClass) that lives for the life of the application (possibly
> a singleton instance). When it is instantiated it obtains a Category, but
> at that point in time there is no Category in the hierarchy specifically
> for instances of somepackage.SomeClass, therefore it receives the root
> Categeory; lets say that Category ignores all messages of TRACE priority.
> At some later point, the administrator sees some fishy behaviour in the
> system, and suspects somepackage.SomeClass to be responsible. Therefore she
> wants to turn on the tracing for somepackage.SomeClass, but not without
> having to shut the system down and deny service to the users (the unusual
> behaviour is not critical at this point). So she updates the configuration
> of the logging subsystem to include a Category for somepackage.SomeClass,
> picking up the TRACE priority messages and dumps them into a logfile.
> However, the instance of somepackage.SomeClass has already obtained its
> Category instance.
> 

Hi James,

The way I understand it, you should have had a specific Category
instance corresponding to somepackage.SomeClass to begin with.  It will
inherit the default priority from the root until you assign one
differently.

-- 
Beware of bugs in the above code.  I have
only proved it correct, not tried it.
-Don Knuth

---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: log4j-user-help@jakarta.apache.org