Hi, lgoback seems to solve some problems that log4j has, but I did not yet find the answer to my most pressign question: Does logback handle multiple configurations in a controllable manner? The crucial problem with log4j was its great propularity not only with application developers but also with library developers that sometimes packed an log4j confguration file into their jars. So in almost every project it could happen that one did configure log4j and only get strange or even no output because ther is some other log4j configration overriding the one intended by oneself. If logback improves this behavior of log4j I'd be switching immediately with flying colors! Regards, jens This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
Hello Jens, Logback uses a configuration policy that follows three steps: 1. Check if a logback.xml file is found. 2. If step 1 fails, check if a logback-test-xml file is found 3. If step 2 fails, auto-configure itself with a basic ConsoleAppender. In step 1, the first logback.xml file that is found is used. If you have multiple configuration files available, with the same name, it might cause you some trouble. To prevent this, you can precise the file you want logback to use by using the JoranConfigurator directly. You can also use the ContextSelector[1] to specify the name of the file you wish to load. This way, you'll never have the problem of "first seen, first loaded". Regards, Sébastien [1]http://logback.qos.ch/manual/contextSelector.html Hausherr, Jens wrote:
Hi,
lgoback seems to solve some problems that log4j has, but I did not yet find the answer to my most pressign question: Does logback handle multiple configurations in a controllable manner?
The crucial problem with log4j was its great propularity not only with application developers but also with library developers that sometimes packed an log4j confguration file into their jars.
So in almost every project it could happen that one did configure log4j and only get strange or even no output because ther is some other log4j configration overriding the one intended by oneself.
If logback improves this behavior of log4j I'd be switching immediately with flying colors!
Regards, jens
This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.
------------------------------------------------------------------------
_______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/
I see the value in simple and very straightforward rules for configuration. However, this is seems too restrictive. In my case, I have several components in a test infrastructure that run out of the same classpath but use different logging configurations. Currently, I use the log4j.configuration system property to specify the configuration to use when each component is started. How would I achieve this using logback? anders Sébastien Pennec wrote:
Hello Jens,
Logback uses a configuration policy that follows three steps:
1. Check if a logback.xml file is found. 2. If step 1 fails, check if a logback-test-xml file is found 3. If step 2 fails, auto-configure itself with a basic ConsoleAppender.
-- View this message in context: http://www.nabble.com/Logback-configuration-tf3266547.html#a9417261 Sent from the Logback User mailing list archive at Nabble.com.
Hello Anders, Could you describe your environment more precisely? We may solve your situation with features that are already available in logback. Would the ContextSelector[1] help in your case? With the ContextSelector, you can specify a name for each of your applications' context and the name of the configuration file they should use. It uses JNDI to ensure that all applications are in a separate environment. Cheers, Sébastien [1]http://logback.qos.ch/manual/contextSelector.html Anders Wallgren wrote:
I see the value in simple and very straightforward rules for configuration. However, this is seems too restrictive.
In my case, I have several components in a test infrastructure that run out of the same classpath but use different logging configurations. Currently, I use the log4j.configuration system property to specify the configuration to use when each component is started.
How would I achieve this using logback?
anders
Sébastien Pennec wrote:
Hello Jens,
Logback uses a configuration policy that follows three steps:
1. Check if a logback.xml file is found. 2. If step 1 fails, check if a logback-test-xml file is found 3. If step 2 fails, auto-configure itself with a basic ConsoleAppender.
-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/
We're not running inside a J2EE container, rather this is a set of standalone applications launched out of the same classpath. As it stands, I don't think ContextSelector will help, unless there's some custom implementation of that interface that I could put together to do the right thing. I'm not yet familiar enough with logback to answer that myself, so your input is appreciated. anders Sébastien Pennec wrote:
Hello Anders,
Could you describe your environment more precisely? We may solve your situation with features that are already available in logback.
Would the ContextSelector[1] help in your case? With the ContextSelector, you can specify a name for each of your applications' context and the name of the configuration file they should use. It uses JNDI to ensure that all applications are in a separate environment.
Cheers,
Sébastien
-- View this message in context: http://www.nabble.com/Logback-configuration-tf3266547.html#a9446180 Sent from the Logback User mailing list archive at Nabble.com.
Hello Anders, If you don't have a J2EE container, using a context selector is a major overkill. If you tell us that it would not be possible to package a different copy of logback.xml in each standalone application, then we will add the functionality you requested, i.e. specifying the configuration file through a system property. (I am not very fond of this feature, but if you really need it, we'll be happy to oblige.) After you have ascertained that packaging a distinct copy of logback.xml in each application is not an option, could you please you file a bug/enhancement report? At 01:30 AM 3/13/2007, Anders Wallgren wrote:
We're not running inside a J2EE container, rather this is a set of standalone applications launched out of the same classpath.
As it stands, I don't think ContextSelector will help, unless there's some custom implementation of that interface that I could put together to do the right thing. I'm not yet familiar enough with logback to answer that myself, so your input is appreciated.
anders
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch
I thought that there was some agreement that Joran would (or should) include the capability to include a file based on a system property, which provides exactly the required functionality without making this a special case. A way to switch the configuration at runtime is a hard requirement for several applications I develop. Making this part of Joran (possibly providing a short sample that gets everything from a property) seems like a great solution that could be helpful in many situations (especially with conditionals and regex captures). There was an email thread covering this on 2/8. Thanks, Andy Gerweck -----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Ceki Gülcü Sent: Tuesday, March 13, 2007 2:18 PM To: logback users list; logback-user@qos.ch Subject: Re: [logback-user] Logback configuration Hello Anders, If you don't have a J2EE container, using a context selector is a major overkill. If you tell us that it would not be possible to package a different copy of logback.xml in each standalone application, then we will add the functionality you requested, i.e. specifying the configuration file through a system property. (I am not very fond of this feature, but if you really need it, we'll be happy to oblige.) After you have ascertained that packaging a distinct copy of logback.xml in each application is not an option, could you please you file a bug/enhancement report? At 01:30 AM 3/13/2007, Anders Wallgren wrote:
We're not running inside a J2EE container, rather this is a set of standalone applications launched out of the same classpath.
As it stands, I don't think ContextSelector will help, unless there's some custom implementation of that interface that I could put together to do the right thing. I'm not yet familiar enough with logback to answer that myself, so your input is appreciated.
anders
-- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user *************************************************************************** The information contained in this communication is confidential, is intended only for the use of the recipient named above, and may be legally privileged. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please resend this communication to the sender and delete the original message or any copy of it from your computer system. Thank You. ****************************************************************************
Hello Andy and Anders, We've modified Joran to add this feature yesterday. The repository version now allows you to set an <include> element in a configuration file, and set a file="" attribute. This attribute can be specified by using a property. We could have: <configuration> <include path="${path.to.file}" /> </configuration> The target file must use the following elements: <included> <!-- add here any configuration element: Appender, layout, logger, ... --> </included> Would that do the trick you, Anders? Sébastien Gerweck Andy - agerwe wrote:
I thought that there was some agreement that Joran would (or should) include the capability to include a file based on a system property, which provides exactly the required functionality without making this a special case.
A way to switch the configuration at runtime is a hard requirement for several applications I develop. Making this part of Joran (possibly providing a short sample that gets everything from a property) seems like a great solution that could be helpful in many situations (especially with conditionals and regex captures).
There was an email thread covering this on 2/8.
Thanks, Andy Gerweck
-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Ceki Gülcü Sent: Tuesday, March 13, 2007 2:18 PM To: logback users list; logback-user@qos.ch Subject: Re: [logback-user] Logback configuration
Hello Anders,
If you don't have a J2EE container, using a context selector is a major overkill. If you tell us that it would not be possible to package a different copy of logback.xml in each standalone application, then we will add the functionality you requested, i.e. specifying the configuration file through a system property. (I am not very fond of this feature, but if you really need it, we'll be happy to oblige.)
After you have ascertained that packaging a distinct copy of logback.xml in each application is not an option, could you please you file a bug/enhancement report?
At 01:30 AM 3/13/2007, Anders Wallgren wrote:
We're not running inside a J2EE container, rather this is a set of standalone applications launched out of the same classpath.
As it stands, I don't think ContextSelector will help, unless there's some custom implementation of that interface that I could put together to do the right thing. I'm not yet familiar enough with logback to answer that myself, so your input is appreciated.
anders
-- Sébastien Pennec sebastien@qos.ch Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/
Looks reasonable -- I'll pull the sources and play around with it. anders Sébastien Pennec wrote:
Hello Andy and Anders,
We've modified Joran to add this feature yesterday.
The repository version now allows you to set an <include> element in a configuration file, and set a file="" attribute. This attribute can be specified by using a property.
We could have:
<configuration> <include path="${path.to.file}" /> </configuration>
The target file must use the following elements:
<included> <!-- add here any configuration element: Appender, layout, logger, ... --> </included>
Would that do the trick you, Anders?
Sébastien
Gerweck Andy - agerwe wrote:
I thought that there was some agreement that Joran would (or should) include the capability to include a file based on a system property, which provides exactly the required functionality without making this a special case.
A way to switch the configuration at runtime is a hard requirement for several applications I develop. Making this part of Joran (possibly providing a short sample that gets everything from a property) seems like a great solution that could be helpful in many situations (especially with conditionals and regex captures).
There was an email thread covering this on 2/8.
Thanks, Andy Gerweck
-----Original Message----- From: logback-user-bounces@qos.ch [mailto:logback-user-bounces@qos.ch] On Behalf Of Ceki Gülcü Sent: Tuesday, March 13, 2007 2:18 PM To: logback users list; logback-user@qos.ch Subject: Re: [logback-user] Logback configuration
Hello Anders,
If you don't have a J2EE container, using a context selector is a major overkill. If you tell us that it would not be possible to package a different copy of logback.xml in each standalone application, then we will add the functionality you requested, i.e. specifying the configuration file through a system property. (I am not very fond of this feature, but if you really need it, we'll be happy to oblige.)
After you have ascertained that packaging a distinct copy of logback.xml in each application is not an option, could you please you file a bug/enhancement report?
At 01:30 AM 3/13/2007, Anders Wallgren wrote:
We're not running inside a J2EE container, rather this is a set of standalone applications launched out of the same classpath.
As it stands, I don't think ContextSelector will help, unless there's some custom implementation of that interface that I could put together to do the right thing. I'm not yet familiar enough with logback to answer that myself, so your input is appreciated.
anders
-- Sébastien Pennec sebastien@qos.ch
Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch/ _______________________________________________ Logback-user mailing list Logback-user@qos.ch http://qos.ch/mailman/listinfo/logback-user
-- View this message in context: http://www.nabble.com/Logback-configuration-tf3266547.html#a9499385 Sent from the Logback User mailing list archive at Nabble.com.
participants (5)
-
Anders Wallgren -
Ceki Gülcü -
Gerweck Andy - agerwe -
Hausherr, Jens -
Sebastien Pennec