I think this is very important fature that Log4j should have.

In my web application, I have to set  system property to point to my config
file. This is kind of not good. Sometimes if I am deploying my application
in some ones server (like a Web Hosting Service Provider), I will not be
able to have such a system property, nor I could change the startup script
of the app server . So there should be some other way to do this.

What I suggest is:

We could include a new Element in the config file <PRIMARY/>

If this element is present then that config file should loaded by the Log4J.
This way the component providers , could include the config without this
Element. And the user in his config could have this Element and be relaxed
that his config file will be used for the logging.

I have not seen the Log4J source. This is just a suggestion

FEEDBACKS pls

--Siva Jagadeesan

-----Original Message-----
From: Ceki G�lc� [mailto:[EMAIL PROTECTED]
Sent: Friday, March 28, 2003 2:06 PM
To: Log4J Users List
Subject: Re: Inherited Logger Config?


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