June 2008 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-52) Allow multiple addresses for "to" property of SMTPAppender
by JIRA Administrator (JIRA) 11 Jul '12

11 Jul '12

Allow multiple addresses for "to" property of SMTPAppender ---------------------------------------------------------- Key: LBCLASSIC-52 URL: http://jira.qos.ch/browse/LBCLASSIC-52 Project: logback-classic Issue Type: Improvement Reporter: Andrey Utkin Assignee: Ceki Gulcu SMTPAppender don`t allow to specify multiple addresses in single "to" property. So that, it is (almost?) impossible to specify multiple "to" addresses via variable substitution. We should know exact number of addresses (variables) to specify appropriate quantity of <to> elements. But number of "to" addresses could be changed during application using and differ from customer to customer. So, IMFO it will be helpful to allow specifying multiple addresses in one <to> element. Multiple addresses could be separated by comma, for example (as comma is not valid character for email address). Right now we are using simple workaround. We subclass SMTPAppender and overwrite addTo(): {code} @Override public void addTo(String to) { StringTokenizer st = new StringTokenizer(to, ","); while(st.hasMoreTokens()) { super.addTo(st.nextToken().trim()); } } {code} This solution works just fine for us. May be it will be good to include this feature in core logback too. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 6

[JIRA] Created: (LBCORE-51) LoggerFactory doesnt respect custom ContextSelector
by Paul Gregoire (JIRA) 28 Dec '08

28 Dec '08

LoggerFactory doesnt respect custom ContextSelector --------------------------------------------------- Key: LBCORE-51 URL: http://jira.qos.ch/browse/LBCORE-51 Project: logback-core Issue Type: Bug Environment: Windows XP64, Java 6, Red5 v0.7.1-dev, Logback 0.9.9, Slf4j 1.5.0 Reporter: Paul Gregoire Assignee: Logback dev list I have found that calling LoggerFactory.getLogger(xxxx) does not make calls to my custom context selector. I expect to see a call to getLoggerContext() but I dont. Do I need to create my own LoggerFactory impl to get my web context apps and red5 apps to use their own Loggers? Main Red5 trunk (dev) http://svn1.cvsdude.com/osflash/red5/java/server/trunk/ My logger implementations http://svn1.cvsdude.com/osflash/red5/java/server/trunk/src/org/red5/logging/ Example JSP I used to test the log context selection <%@page import="org.slf4j.Logger,org.slf4j.LoggerFactory,org.slf4j.impl.StaticLoggerBinder,ch.qos.logback.classic.LoggerContext,org.red5.logging.LoggingContextSelector"%> <html> <body> <% // Logger log = LoggerFactory.getLogger("TestJsp"); log.info("This is a test log entry from a web context"); // LoggingContextSelector selector = (LoggingContextSelector) StaticLoggerBinder.SINGLETON.getContextSelector(); LoggerContext ctx = selector.getLoggerContext(mywebappcontextname); Logger log2 = ctx.getLogger("TestJsp"); log2.info("This is a test log entry from a web context attempt 2"); %> </body> </html> The first log goes to the "default" logger context and the second goes to the correct one. I also implemented the Servlet filter and context listener for this tested context. Anything I can do to help, please let me know.. I am getting extremely frustrated with this logging stuff and I'm sure our users are as well. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 13

[JIRA] Created: (LBCLASSIC-53) Add MDC Level Filtering
by Ralph Goers (JIRA) 27 Oct '08

27 Oct '08

Add MDC Level Filtering ----------------------- Key: LBCLASSIC-53 URL: http://jira.qos.ch/browse/LBCLASSIC-53 Project: logback-classic Issue Type: New Feature Environment: All Reporter: Ralph Goers Assignee: Logback dev list Attachments: MDCLevelFilter.zip The company I work for is an Application Service Provider. Requests to the same software running in a single JVM might be on behalf of any one of these companies. In addition, our middle tier contains services that my be called from several different products and are run on behalf of a user of one of these companies. Operationally, we require the ability to be able to filter based on company, product, possibly the end user or several other criteria. The TurboFilter provided allows individual values for keys in the MDC to be associated with a logging level. So if the MDC contains a key for the company the TurboFilter can be configured with the name of the company and the corresponding logging level. So if CompanyA's level is set to debug while the default level is error, only debug events for CompanyA will be passed on. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

4 10

[JIRA] Created: (LBGENERAL-18) Attachments are lost during migration from bugzilla to JIRA
by JIRA Administrator (JIRA) 19 Aug '08

19 Aug '08

Attachments are lost during migration from bugzilla to JIRA ----------------------------------------------------------- Key: LBGENERAL-18 URL: http://jira.qos.ch/browse/LBGENERAL-18 Project: logback-general Issue Type: Bug Reporter: Roland Klein Assignee: Ceki Gulcu Attachments are lost during migration from bugzilla to JIRA The Attachments are lost during migration from bugzilla to JIRA. e.g. bugzilla #107 -> JIRA #32 Patch is gone -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

Testing, please ignore
by Ceki Gulcu 26 Jun '08

26 Jun '08

Hello, OK, so contrary to what the subject line says, you are actually reading this message. :-) The main QOS.ch server crashed due to a permanent failure of its hard drive. We are in the process of reconstructing the server on a brand new machine using data available from backups. This message is to test that the logback-dev mailing list is again operational. Cheers, -- Ceki Gülcü QOS.ch is looking to hire talented developers located in Switzerland. If interested, please contact c e k i AT q o s . c h

1 0

What's the exact difference between File and Presentation Header?
by Lilianne E. Blaze 23 Jun '08

23 Jun '08

Hello, I'm trying to write a custom Layout, I have it pretty much planned, but there's one thing I don't know - what's the exact difference between FileHeader and PresentationHeader? As in - which one is meant for what exactly? Neither the source nor Google were clear on that. Greetings, Lilianne

1 0

[JIRA] Commented: (LBCORE-43) support looking up property files from classpath resources
by Eduardo Ito (JIRA) 22 Jun '08

22 Jun '08

[ http://jira.qos.ch/browse/LBCORE-43?page=com.atlassian.jira.plugin.system.i… ] Eduardo Ito commented on LBCORE-43: ----------------------------------- I've implemented it as sugested. The affected files are listed below and are attached in a zip file. logback-core/src/main/java/ch/qos/logback/core/joran/action/Action.java logback-core/src/main/java/ch/qos/logback/core/joran/action/PropertyAction.java logback-core/src/test/java/ch/qos/logback/core/joran/action/PropertyActionTest.java logback-core/src/test/resources/input/joran/propertyActionTest.properties Could some core developer review it, and if there is no problem, and commit it? I would like to see it in the next release. > support looking up property files from classpath resources > ---------------------------------------------------------- > > Key: LBCORE-43 > URL: http://jira.qos.ch/browse/LBCORE-43 > Project: logback-core > Issue Type: Bug > Components: Joran > Affects Versions: unspecified > Environment: Operating System: Linux > Platform: PC > Reporter: Bruno Navert > Assignee: Logback dev list > Attachments: res.zip > > > Joran's support for property files (through PropertyAction) is useful, but it only reads filesystem files. It would be useful to be able to read classpath resources, that way the logback.xml file as well as its properties files would be located in the same place (in the class path). > Furthermore, it would be useful for both resource and file lookups to perform system property resolution in the included file names. > For instance: > <substitutionProperty resource="config/logback/logback-${CONFIG_MODE}.properties"/> > where CONFIG_MODE is a system property. In our environment this is set to something like DEV or QA or PROD, which would allow use of substitution properties that change based on the environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Updated: (LBCORE-43) support looking up property files from classpath resources
by Eduardo Ito (JIRA) 22 Jun '08

22 Jun '08

[ http://jira.qos.ch/browse/LBCORE-43?page=com.atlassian.jira.plugin.system.i… ] Eduardo Ito updated LBCORE-43: ------------------------------ Attachment: res.zip > support looking up property files from classpath resources > ---------------------------------------------------------- > > Key: LBCORE-43 > URL: http://jira.qos.ch/browse/LBCORE-43 > Project: logback-core > Issue Type: Bug > Components: Joran > Affects Versions: unspecified > Environment: Operating System: Linux > Platform: PC > Reporter: Bruno Navert > Assignee: Logback dev list > Attachments: res.zip > > > Joran's support for property files (through PropertyAction) is useful, but it only reads filesystem files. It would be useful to be able to read classpath resources, that way the logback.xml file as well as its properties files would be located in the same place (in the class path). > Furthermore, it would be useful for both resource and file lookups to perform system property resolution in the included file names. > For instance: > <substitutionProperty resource="config/logback/logback-${CONFIG_MODE}.properties"/> > where CONFIG_MODE is a system property. In our environment this is set to something like DEV or QA or PROD, which would allow use of substitution properties that change based on the environment. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[Bug 1] Appender interface managing Layouts?
by bugzilla-daemon＠pixie.qos.ch 09 Jun '08

09 Jun '08

show_bug.cgi?id=1 Ceki Gulcu <noreply.ceki(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|noreply.ceki(a)qos.ch | --- Comment #2 from Ceki Gulcu <noreply.ceki(a)qos.ch> 2008-06-09 16:46:16 --- editing should fail -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0

[Bug 1] Appender interface managing Layouts?
by bugzilla-daemon＠pixie.qos.ch 09 Jun '08

09 Jun '08

show_bug.cgi?id=1 Ceki Gulcu <noreply.ceki(a)qos.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |noreply.ceki(a)qos.ch --- Comment #1 from Ceki Gulcu <noreply.ceki(a)qos.ch> 2008-06-09 16:42:43 --- testing -- Configure bugmail: userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.

1 0