Re: Default configuration not seeing my appender
Erik Price wrote: Hi, I'm having trouble with my first excursion into Log4J. I'm using an Ant script to compile my project and then call JUnit tests. I have no logging statements in the JUnit tests, but I do have logging statements in my application. I have confirmed (via System.out.print) that there is a System Property whose key is log4j.configuration, and that this is a valid file on my Win2k/Cygwin filesystem, and the contents of that file are as follows: [...] Does anyone see some problem with my log4j.configuration Properties file that would cause the Default Initialization to fail with the message that it can't find an Appender? It works fine when my Properties file is in my classpath, but according to the docs, this should work fine if I am passing in the log4j.configuration System Property, which I am. Forgive me for responding to my own post, but I think I've found the answer and hopefully this might help someone else down the road. However, if I'm mistaken or someone can confirm for me that I'm -not- mistaken, that would be awesome. It seems that it had nothing to do with my log4j.properties file, which makes sense since it worked fine if I just let the default initialization pick it up from the class loader's path (i.e., by not specifying a log4j.configuration System Property). However, apparently on Windows a file path does not translate directly to a URL. The short manual on the Log4J site explicitly states: quote 2. Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value log4j.properties. 3. Attempt to convert the resource variable to a URL. /quote What worked for me was changing the value of the log4j.configuration System Property from a simple Windows file path to file:// + a simple Windows file path. Is this the way it's supposed to work? I just want to make sure so that I don't continue to develop under a mistaken impression, because the above evaluates to an invalid URL (file://D:\User Profiles\eprice\My Documents\dev\java\projectname). I can use Ant to manipulate that string to use proper (Unix/Java-style) path format, and will do so if anyone can clear me up on this. Thanks, Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Default configuration not seeing my appender
Howdy, Personally, I've encountered nothing but grief when attempting to work with windows-style file paths. (Or more general resource paths, e.g. for JNDI). I don't know if this is a shortcoming of java the language, the File/URI/URL class implementations, the windows file system, or what else, but I don't care. Save yourself time and hassle and work exclusively with unix style paths. Yoav Shapira Millennium ChemInformatics -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 11:04 AM To: Log4J Users List Subject: Re: Default configuration not seeing my appender Erik Price wrote: Hi, I'm having trouble with my first excursion into Log4J. I'm using an Ant script to compile my project and then call JUnit tests. I have no logging statements in the JUnit tests, but I do have logging statements in my application. I have confirmed (via System.out.print) that there is a System Property whose key is log4j.configuration, and that this is a valid file on my Win2k/Cygwin filesystem, and the contents of that file are as follows: [...] Does anyone see some problem with my log4j.configuration Properties file that would cause the Default Initialization to fail with the message that it can't find an Appender? It works fine when my Properties file is in my classpath, but according to the docs, this should work fine if I am passing in the log4j.configuration System Property, which I am. Forgive me for responding to my own post, but I think I've found the answer and hopefully this might help someone else down the road. However, if I'm mistaken or someone can confirm for me that I'm -not- mistaken, that would be awesome. It seems that it had nothing to do with my log4j.properties file, which makes sense since it worked fine if I just let the default initialization pick it up from the class loader's path (i.e., by not specifying a log4j.configuration System Property). However, apparently on Windows a file path does not translate directly to a URL. The short manual on the Log4J site explicitly states: quote 2. Set the resource string variable to the value of the log4j.configuration system property. The preferred way to specify the default initialization file is through the log4j.configuration system property. In case the system property log4j.configuration is not defined, then set the string variable resource to its default value log4j.properties. 3. Attempt to convert the resource variable to a URL. /quote What worked for me was changing the value of the log4j.configuration System Property from a simple Windows file path to file:// + a simple Windows file path. Is this the way it's supposed to work? I just want to make sure so that I don't continue to develop under a mistaken impression, because the above evaluates to an invalid URL (file://D:\User Profiles\eprice\My Documents\dev\java\projectname). I can use Ant to manipulate that string to use proper (Unix/Java-style) path format, and will do so if anyone can clear me up on this. Thanks, Erik - 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]
Re: Default configuration not seeing my appender
You really don't have to worry about it. Ant understands both and Java understands mixed use of / and \ when using file:///. BTW, you can also do relative paths like this and it will work for both UNIX and Windows... file:../WEB-INF/log4j.xml Jake At 11:14 AM 3/28/2003 -0500, you wrote: Shapira, Yoav wrote: Howdy, Personally, I've encountered nothing but grief when attempting to work with windows-style file paths. (Or more general resource paths, e.g. for JNDI). I don't know if this is a shortcoming of java the language, the File/URI/URL class implementations, the windows file system, or what else, but I don't care. Save yourself time and hassle and work exclusively with unix style paths. Yoav, Thanks for your thoughts. I am kind of new to using File I/O on Windows with Java because formerly my only deployment was to a Linux box. I am running Cygwin on Windows, but I believe that only provides me with the convenience of Unix-style file paths in a shell. Do you know of a way that I can force Ant to use Unix-style file paths even though it is technically a Windows machine? Perhaps I should ask on ant-user. At least in my Java code I can use Unix/Java-style file paths. Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Another Default configuration not seeing my appender Question
In the same directory as the build.xml (ant) and gui.xml (jelly) files I'm working with (thats why I'm trying to keep it relative). I've tried using the classpath to add the log4j.xml file but Ant's java task screams: [java] CLASSPATH component C:\eclipse\workspace\project\log4j.xml: java.util.zip.ZipException: error in opening zip file But, I'm sure thats an issue that should be taken up on thier lists or Sun. -Mark Ceki Gülcü wrote: Hi Mark, Where is the log4j.xml file located? At 01:04 PM 3/28/2003 -0500, you wrote: Here's a similar question concerning an appenders error. I'm trying to launch a java program in Ant (Jelly) that uses log4j for logging. I do this via a target that looks somewhat like. target depends=compile name=gui java classname=org.apache.commons.jelly.Jelly fork=true classpathref=classpath arg value=gui.xml/ sysproperty key=log4j.configuration value=log4j.xml/ /java /target I keep getting the errors that look like: Buildfile: build.xml gui: [java] log4j:WARN No appenders could be found for logger (org.apache.commons.jelly.parser.XMLParser). [java] log4j:WARN Please initialize the log4j system properly. My config file looks like: ?xml version=1.0 encoding=UTF-8? !DOCTYPE log4j:configuration SYSTEM log4j.dtd log4j:configuration debug=true appender name=CONSOLE class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%-5p - %m\n/ /layout /appender logger name=org additivity=false level value=debug/ appender-ref ref=CONSOLE/ /logger root priority value=debug/ appender-ref ref=CONSOLE/ /root /log4j:configuration Is there something obvious that I'm missing here? -Mark Diggory - 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]
RE: Inherited Logger Config?
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]
RE: Inherited Logger Config?
At 02:14 PM 3/28/2003 -0600, Jagadeesan,Sivakumar wrote: 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 don't understand. What happens if the primary/ element is NOT present? I have not seen the Log4J source. This is just a suggestion FEEDBACKS pls --Siva Jagadeesan -Original Message- -- Ceki - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Inherited Logger Config?
If the Primary/ element is not present then Log4J could load the configuration file as it is doing rite now. Infact if two config files have Primary/ element, then Log4J will load the first one --Siva Jagadeesan -Original Message- From: Ceki Gülcü [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 2:24 PM To: Log4J Users List Subject: RE: Inherited Logger Config? At 02:14 PM 3/28/2003 -0600, Jagadeesan,Sivakumar wrote: 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 don't understand. What happens if the primary/ element is NOT present? I have not seen the Log4J source. This is just a suggestion FEEDBACKS pls --Siva Jagadeesan -Original Message- -- 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]
RE: Inherited Logger Config?
Yah I think we could do that :) Yah as you said it is going to one configuration file to configure another configuration :) --Siva Jagadeesan -Original Message- From: Erik Price [mailto:[EMAIL PROTECTED] Sent: Friday, March 28, 2003 2:21 PM To: Log4J Users List Subject: Re: Inherited Logger Config? Jagadeesan,Sivakumar wrote: 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. I'm not writing to disagree with you, in fact what I'm about to say is sort of off-topic -- but couldn't you write a ContextListener that sets a System Property by reading a configuration file (of your own creation)? Admittedly this gets a little convoluted -- you're using a config file to tell a ContextListener to set a System Property pointing to another config file that tells Log4J how to configure itself. But in theory does it work? Erik - 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]
Re: Inherited Logger Config?
See: http://nagoya.apache.org/wiki/apachewiki.cgi?Log4JProjectPages/UsefulCode especially the links for... Some custom repository selectors can be found in the current log4j cvs at http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/selector/. They will be released, in some packaged form, with v1.3, but they are compatible with current v1.2.X. -- Web Application - Servlet related log4j classes can be found in the current log4j cvs at http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/http://cvs.apache.org/viewcvs/jakarta-log4j-sandbox/src/java/org/apache/log4j/servlet/. They will be released, in some packaged form, with v1.3, but they are compatible with the current v1.2.X. I wrote the selectors and the InitContextListener . The javadoc should explain how to use this stuff. You won't have to worry about log4j accidentally loading the wrong configuration file using this setup. Jake At 03:20 PM 3/28/2003 -0500, you wrote: Jagadeesan,Sivakumar wrote: 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. I'm not writing to disagree with you, in fact what I'm about to say is sort of off-topic -- but couldn't you write a ContextListener that sets a System Property by reading a configuration file (of your own creation)? Admittedly this gets a little convoluted -- you're using a config file to tell a ContextListener to set a System Property pointing to another config file that tells Log4J how to configure itself. But in theory does it work? Erik - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Inherited Logger Config?
Wouldn't XML inclusions work? Assume the common config file is : ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration You can change it to ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd [ !ENTITY loggers SYSTEM loggers.xml !ENTITY appenders SYSTEM ap.xml ] log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' ap; appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration This way the ap.xml and loggers.xml files could be local. Does this help? At 03:38 PM 3/28/2003 -0500, you wrote: 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,
Re: Inherited Logger Config?
I bet this would work, I'll give it a try and let you know how it goes. Ceki Gülcü wrote: Wouldn't XML inclusions work? Assume the common config file is : ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration You can change it to ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd [ !ENTITY loggers SYSTEM loggers.xml !ENTITY appenders SYSTEM ap.xml ] log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' ap; appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration This way the ap.xml and loggers.xml files could be local. Does this help? At 03:38 PM 3/28/2003 -0500, you wrote: 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
Re: Inherited Logger Config?
It does work with my environment but I have to use the file: protocol in the file name: !DOCTYPE log4j:configuration SYSTEM log4j.dtd [ !ENTITY loggers SYSTEM file:loggers.xml ] -Mark Mark R. Diggory wrote: I bet this would work, I'll give it a try and let you know how it goes. Ceki Gülcü wrote: Wouldn't XML inclusions work? Assume the common config file is : ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration You can change it to ?xml version=1.0 encoding=UTF-8 ? !DOCTYPE log4j:configuration SYSTEM log4j.dtd [ !ENTITY loggers SYSTEM loggers.xml !ENTITY appenders SYSTEM ap.xml ] log4j:configuration xmlns:log4j='http://jakarta.apache.org/log4j/' ap; appender name=STDOUT class=org.apache.log4j.ConsoleAppender layout class=org.apache.log4j.PatternLayout param name=ConversionPattern value=%r [%t] %p %c - %m%n/ /layout /appender loggers; root level value =debug/ appender-ref ref=STDOUT/ /root /log4j:configuration This way the ap.xml and loggers.xml files could be local. Does this help? At 03:38 PM 3/28/2003 -0500, you wrote: 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
