Mostly, I'm thinking about the folowing case:

My application has two types of usercases, Developer (me and others), and the Users (people who install and use the package).

1.) For the "Users" case we keep a copy of the logging config in the cvs tree with the rest of the package.

2.) It'd be nice as "Developers" to be able to augment this default logging config when we like to do debugging. It'd be ideal if this were an external copy to that of the one in the cvs, this is because its often the case that my developers step on eachothers toes alot by altering the default config file and then doing things like accidentally commiting it.

3.) It's sometimes the case that info in the cvs copy of the config can get changed on purpose (say if a package is "refactored"). So, it would be good if this were available to the developer as soon as they updated from the cvs.

4.) It'd also be nice to not have to alter any of the config scripts to accomplish the use of a different configuration (say by recognizing the presence of another developer log4j config file).

So, in this case there is logging info that is pertenent to the application in the cvs copy, developers as well as users like to see this information. We like to keep it "standardized" somewhat. If a developer wants to see more, it would be nice to "augment" the logging content of that "standardized" config with an alternate configuration containing additional appenders/loggers that each developer may like to see (and each developer may have different logging requirements).

Thats about as detailed as I was thinking.
Mark

Ceki Gülcü wrote:
Mark,

The question is interesting. Would it be possible for you to describe a scenario where such capability would be helpful?

To answer your question, searching for multiple paths for config files at start up time is necessarily a capability that needs to be in log4j itself. I don't see how it could be done without modifying log4j code. Does this answer your question?

At 02:58 PM 3/28/2003 -0500, you wrote:

I was mostly interested if it could be done outside of log4j, via some sort of configuration layout. Not suggesting it as a requriement of any kind in the devlopment of log4j itself. I was just wondering if anyone had attempted something like this?

-Mark

Shapira, Yoav wrote:

Howdy,
IMHO that's too complicated to be worth it.  There are too many
possibilities for confusion.  The simpler we can make configuration, the
better.  -1 on that.
Yoav Shapira
Millennium ChemInformatics


-----Original Message-----
From: Mark R. Diggory [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 2:28 PM
To: Log4J Users List
Subject: Inherited Logger Config?

Are there any thoughts/Ideas on "Inherited" or "Hierarchical"
configuration approaches with Log4J. I'm referring specifically to the
idea that On could have multiple log4j configuration files that
configure logging on a particular runtime. Say for instance:

a search order where

1.) user.home
2.) classpath overides user home
(and order overides config earlier to later)
3.) finally commandline overides classpath

This way one could have some generalized logging config as a user, and
then the application can setup its logging config overiding any user
settings that happen to already exist, and then the user could
specialize at runtime from the commandline.

Mark


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.


---------------------------------------------------------------------
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]


-- 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]



Reply via email to