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

[JIRA] Created: (LBCORE-52) Make SyslogAppenderBase fields protected
by Anton Tagunov (JIRA) 27 Dec '12

27 Dec '12

Make SyslogAppenderBase fields protected ---------------------------------------- Key: LBCORE-52 URL: http://jira.qos.ch/browse/LBCORE-52 Project: logback-core Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Hi! We'd like to customize some of SyslogAppender. Since SyslogAppenderBase class is public and is a base class by destination would it be appropriate to have all of the fields be designated as 'protected'? -- 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 5

[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

Least-effort logging with bytecode modification
by Ramon Nogueira 18 Nov '08

18 Nov '08

Hi At the company I work for we use the same logging pattern almost everywhere, for example: public class SomeClass { private static final Logger log = LoggerFactory.getLogger(SomeClass.class); public void someMethod() { log.debug("A log message"); } } I would like to simplify this to: import static logging.LogApi.*; public class SomeClass { private void someMethod(String someArg) { debug("A log message"); // from static import } } And then have code equivalent to the former generated (preferably at class load time) dynamically. This could save us hundreds of lines of boilerplate code and provide other interesting options like declarative rules regarding the "injected" logger name, perhaps through class/method annotations and pre-calculating the source location information. I thought of implementing this with AspectJ but its probably easier to just use ASM directly for such a simple case. Any ideas/suggestions/precedents? Thanks Ramon

9 22

[JIRA] Created: (LBCLASSIC-59) LogbackErrorListener
by Anton Tagunov (JIRA) 29 Oct '08

29 Oct '08

LogbackErrorListener -------------------- Key: LBCLASSIC-59 URL: http://jira.qos.ch/browse/LBCLASSIC-59 Project: logback-classic Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Priority: Minor Presently we can only poll StatusManager for errors. It would be nice to be able to subscribe to these messages. One idea was to allow custom StatusManager implementations. This sounds like a nice and sane idea in its own right. However I feel that providing subscription to error events and allowing users to provide alternative StatusManager implementations are orthogonal concerns. In fact I feel that application should be able to subscribe to logback errors no matter what StatusManager is used stock or custom. In other words I suggest it to be part of StatusManager interface/contract to provide subscriptions. Which brings me back to the idea that it would be best to provide subscription (listener) facility in the standards StatusManager. On yet another account http://jira.qos.ch/browse/LBCLASSIC-58 may be enough for most practical users. And I suspect that the most common LogbackErrorListener implementation will simply log to System.out. In any case we badly need to get these errors out of Logback. BTW an alternative implemenation of LogbackListener might log to a file. -- 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

5 5

[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: (LBCLASSIC-58) Print Logback own erros to System.out if debug is enabled?
by Anton Tagunov (JIRA) 04 Sep '08

04 Sep '08

Print Logback own erros to System.out if debug is enabled? ---------------------------------------------------------- Key: LBCLASSIC-58 URL: http://jira.qos.ch/browse/LBCLASSIC-58 Project: logback-classic Issue Type: Improvement Reporter: Anton Tagunov Assignee: Logback dev list Priority: Minor Hello Ceki, when debug is enabled lots of messages to to System.out anyway. Do you think it would be a good idea to also print messages going to StatusManager to System.out? Apparently there is huge demand for this feature. -- 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

5 13

[JIRA] Created: (LBSITE-16) Clarify manual/joran wording
by Ceki Gulcu (JIRA) 25 Aug '08

25 Aug '08

Clarify manual/joran wording ---------------------------- Key: LBSITE-16 URL: http://jira.qos.ch/browse/LBSITE-16 Project: logback-site Issue Type: Bug Reporter: Ceki Gulcu Assignee: Logback dev list Reported by Anton Tagunov in bugzilla.slf4j.org instead of here. See http://bugzilla.slf4j.org/show_bug.cgi?id=87 -- 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 1

[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

[JIRA] Created: (LBCLASSIC-60) chapter on Markers
by Ceki Gulcu (JIRA) 15 Aug '08

15 Aug '08

chapter on Markers ------------------ Key: LBCLASSIC-60 URL: http://jira.qos.ch/browse/LBCLASSIC-60 Project: logback-classic Issue Type: Task Reporter: Ceki Gulcu Assignee: Logback dev list Priority: Critical - SECURITY marker, see http://www.owasp.org/index.php/How_to_add_a_security_log_level_in_log4j - ENTER/EXIT markers, both containing a FLOW marker as a child so as to disable both in one statement - PROFILER marker -- 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 1