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

[JIRA] Created: (LBCLASSIC-120) Joran configuration not working in OSGi environment
by Pavol Juhos (JIRA) 03 Dec '09

03 Dec '09

Joran configuration not working in OSGi environment --------------------------------------------------- Key: LBCLASSIC-120 URL: http://jira.qos.ch/browse/LBCLASSIC-120 Project: logback-classic Issue Type: Bug Components: joran Affects Versions: 0.9.15 Environment: OSGi Service Platform Release 4 Reporter: Pavol Juhos Assignee: Logback dev list When running in OSGi environment, JoranConfigurator throws a ClassCastException when trying to parse the Logback XML configuration file. The problem seems to be caused by OSGi-unfriendly JAXP parser discovery mechanism as suggested by Dieter Wimberger in his blog post -- http://wimpi.coalevo.net/2008/04/hack-how-to-use-logback.html "[...] JAXP discovery mechanism assume visibility of the parser through the context ClassLoader of the actual thread, which may cause some troubles." Observed exception stack trace: Failed to auto configure default logger context Reported exception: ch.qos.logback.core.joran.spi.JoranException: Parser configuration error occured at ch.qos.logback.core.joran.event.SaxEventRecorder.recordEvents(SaxEventRecorder.java:63) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:105) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:76) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:40) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:47) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:108) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:85) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:56) at org.slf4j.LoggerFactory.getSingleton(LoggerFactory.java:189) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:112) at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:105) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:235) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:208) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:221) at com.foo.bar.server.config.Configuration.<clinit>(Configuration.java:244) at com.foo.bar.server.ServerBundleActivator.start(ServerBundleActivator.java:39) at org.apache.felix.framework.util.SecureAction.startActivator(SecureAction.java:589) at org.apache.felix.framework.Felix._startBundle(Felix.java:1671) at org.apache.felix.framework.Felix.startBundle(Felix.java:1588) at org.apache.felix.framework.Felix.setFrameworkStartLevel(Felix.java:1180) at org.apache.felix.framework.StartLevelImpl.run(StartLevelImpl.java:265) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassCastException: org.apache.xerces.jaxp.SAXParserFactoryImpl at javax.xml.parsers.SAXParserFactory.newInstance(Unknown Source) at ch.qos.logback.core.joran.event.SaxEventRecorder.recordEvents(SaxEventRecorder.java:56) ... 21 more -- 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 4

[JIRA] Created: (LBCLASSIC-101) Problem with logback OSGi bundles
by Ceki Gulcu (JIRA) 03 Dec '09

03 Dec '09

Problem with logback OSGi bundles --------------------------------- Key: LBCLASSIC-101 URL: http://jira.qos.ch/browse/LBCLASSIC-101 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.14 Reporter: Ceki Gulcu Assignee: Logback dev list Priority: Critical http://www.slf4j.org/pipermail/user/2009-January/000661.html http://www.slf4j.org/pipermail/user/2009-January/000663.html -- 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 3

[JIRA] Created: (LBCLASSIC-121) Make some of the Import-Package declarations in logback-classic OSGi bundle optional
by Pavol Juhos (JIRA) 25 Nov '09

25 Nov '09

Make some of the Import-Package declarations in logback-classic OSGi bundle optional ------------------------------------------------------------------------------------ Key: LBCLASSIC-121 URL: http://jira.qos.ch/browse/LBCLASSIC-121 Project: logback-classic Issue Type: Improvement Components: Other Affects Versions: 0.9.15 Environment: OSGi Service Platform Release 4 Reporter: Pavol Juhos Assignee: Logback dev list Priority: Minor It might be a good idea to mark some additional packages imported by logback-classis bundle as optional. Namely this applies to packages javax.servlet, javax.servlet.http, javax.management By importing package javax.servlet you are forcing the users to deploy Sevlet API bundle even in non-web application environment. The current <Import-Package> declaration in maven-bundle-plugin configuration: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> Suggested update: <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, javax.servlet.*;resolution:=optional, javax.management;resolution:=optional, * </Import-Package> Feel free to close this as invalid if the above mentioned packages are _always_ required for correct operation of logback-classic. -- 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 3

[JIRA] Created: (LBCLASSIC-108) LOGBack Classic Bundle does not declare ch.qos.logback.core.rolling as Import-Package
by Christian Brensing (JIRA) 18 Nov '09

18 Nov '09

LOGBack Classic Bundle does not declare ch.qos.logback.core.rolling as Import-Package ------------------------------------------------------------------------------------- Key: LBCLASSIC-108 URL: http://jira.qos.ch/browse/LBCLASSIC-108 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Reporter: Christian Brensing Assignee: Logback dev list Priority: Minor The LOGBack Classic Bundle has no Import-Package for ch.qos.logback.core.rolling (and rolling.helper), resulting in a ClassNotFoundException when using e.g. the RollingFileAppender from the Core-Bundle. The ClassNotFoundException will be raised because the Bundle which initializes the LoggerContext (Classic) can not load the Appender from the Core-Bundle. The Bnd-Tool by Peter Kriens and the Maven-Felix-Plugin only detects package dependencies that are imported in java classes. Runtime dependencies like Appenders must be explicitly configured in the bnd-file or pom. This issue is identically to the one I reported for the SpringSource-Bundle-Repository, see https://issuetracker.springsource.com/browse/BRITS-165. -- 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: (LBCORE-98) TimeBasedRollingPolicy: name of file in zip archive is <FileNamePattern>.nanos.tmp
by Anders Wallgren (JIRA) 13 Nov '09

13 Nov '09

TimeBasedRollingPolicy: name of file in zip archive is <FileNamePattern>.nanos.tmp ---------------------------------------------------------------------------------- Key: LBCORE-98 URL: http://jira.qos.ch/browse/LBCORE-98 Project: logback-core Issue Type: Bug Components: Rolling Affects Versions: 0.9.15 Environment: Windows Reporter: Anders Wallgren Assignee: Logback dev list Priority: Minor The name of the filename in the zip archive is a temp filename, based on the FileNamePattern, no the FileNamePattern itself. -- 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 4

[JIRA] Created: (LBCORE-101) OSGi manifest headers too restrictive
by david varnes (JIRA) 12 Nov '09

12 Nov '09

OSGi manifest headers too restrictive ------------------------------------- Key: LBCORE-101 URL: http://jira.qos.ch/browse/LBCORE-101 Project: logback-core Issue Type: Bug Affects Versions: 0.9.15 Reporter: david varnes Assignee: Logback dev list This issue is very similar and could be addressed at the same time as LBCLASSIC-119, LBCLASSIC-121 & LBCLASSIC-131. The Import-Package definition for logback-core requires that the javax.* packages be available at runtime. The pom.xml file and my usage seem to indicate that they should be optional. Attached patch adds javax.* as 'optional' in addition to the exiting janino declaration. thanks ! -- 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-119) Missing Export-Package declarations in logback-classic OSGi bundle
by Pavol Juhos (JIRA) 08 Nov '09

08 Nov '09

Missing Export-Package declarations in logback-classic OSGi bundle ------------------------------------------------------------------ Key: LBCLASSIC-119 URL: http://jira.qos.ch/browse/LBCLASSIC-119 Project: logback-classic Issue Type: Bug Components: Other Affects Versions: 0.9.15 Environment: OSGi environment Reporter: Pavol Juhos Assignee: Logback dev list Priority: Critical logback-classic OSGi bundle doesn't export logback implementation packages. These packages need to be imported by bundles implementing custom logback Appenders etc. The problem is most likely caused a misconfiguration of maven-bundle-plugin in logback-classic POM. Current configuration: <instructions> <Export-Package>ch.qos.logback.classic.*</Export-Package> <Export-Package>org.slf4j.impl;version=1.5.6</Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Suggested configuration: <instructions> <Export-Package>ch.qos.logback.classic.*, org.slf4j.impl;version=1.5.6 </Export-Package> <Import-Package>sun.reflect;resolution:=optional, javax.jms;resolution:=optional, * </Import-Package> <Bundle-RequiredExecutionEnvironment>J2SE-1.5</Bundle-RequiredExecutionEnvironment> </instructions> Second Export-Package declaration seems to override the first one. -- 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 1

[JIRA] Created: (LBCORE-106) TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file.
by Ralph Goers (JIRA) 12 Aug '09

12 Aug '09

TimeBasedRollingPolicy append logs into a old log file, instead of rolling the log file. ---------------------------------------------------------------------------------------- Key: LBCORE-106 URL: http://jira.qos.ch/browse/LBCORE-106 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.15 Environment: Linux, Sun JDK 5 Reporter: Ralph Goers Assignee: Logback dev list It appears that LBCORE-26 was not completely fixed. I have users who seem the be having the same problem. The text below is the relevant portion of the email I received from them. There is same issue today also. Yesterday the nova1a-qa and nova1b-qa servers were restarted and after that the system logged the info to the server.log and server_mc.log files. Today the system logs most info to the server.2009-07-06.log and server_mc.2009-07-06.log files and some info to the server.log and server_mc.log files. Below is example from the nova1a-qa:/opt/jboss/sbfw-V2.0.0-onlineserv-home/server/default/log [akma4116@nova1a-qa:/opt/jboss/sbfw-V2.0.0-onlineserv-home/server/default/log]$ ls -ltr ... -rw-rw-r-- 1 jboss jboss 327312 Jul 5 23:50 server.2009-07-05.log -rw-rw-r-- 1 jboss jboss 327312 Jul 5 23:50 server_mc.2009-07-05.log -rw-rw-r-- 1 jboss jboss 6384 Jul 5 23:58 jboss.log.2009-07-05 -rw-rw-r-- 1 jboss jboss 250839 Jul 6 13:20 server_07_06_09_14_34_54.log -rw-rw-r-- 1 jboss jboss 347440 Jul 6 13:20 server_mc_07_06_09_14_34_54.log -rw-rw-r-- 1 jboss jboss 755260 Jul 6 14:18 console_07_06_09_14_34_54.log -rw-rw-r-- 1 jboss jboss 856101 Jul 6 14:18 server_mc.2009-07-02.log -rw-rw-r-- 1 jboss jboss 912958 Jul 6 14:18 server.2009-07-02.log -rw-rw-r-- 1 jboss jboss 87149 Jul 6 14:34 boot.log -rw-rw-r-- 1 jboss jboss 36091128 Jul 6 23:58 jboss.log.2009-07-06 -rw-rw-r-- 1 jboss jboss 108572 Jul 7 06:30 sbc_ib-exp_HQResponseTime.log -rw-rw-r-- 1 jboss jboss 12810 Jul 7 07:48 server.log -rw-rw-r-- 1 jboss jboss 18207 Jul 7 07:48 server_mc.log -rw-rw-r-- 1 jboss jboss 148904 Jul 7 07:48 console.log -rw-rw-r-- 1 jboss jboss 424746 Jul 7 08:20 ROOT_HQResponseTime.log -rw-rw-r-- 1 jboss jboss 374460 Jul 7 08:25 hyperic-hq_HQResponseTime.log -rw-rw-r-- 1 jboss jboss 231082 Jul 7 08:40 server_mc.2009-07-06.log -rw-rw-r-- 1 jboss jboss 241730 Jul 7 08:40 server.2009-07-06.log -rw-rw-r-- 1 jboss jboss 17574 Jul 7 08:42 sbc_mc-exp_HQResponseTime.log -rw-rw-r-- 1 jboss jboss 556062 Jul 7 08:46 jboss.log [akma4116@nova1a-qa:/opt/jboss/sbfw-V2.0.0-onlineserv-home/server/default/log]$ tail -f server.2009-07-06.log 08:40:00.018 [DefaultQuartzScheduler_Worker-4] DEBUG c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - Exiting getAllPendingIOPUsers. 08:40:00.018 [DefaultQuartzScheduler_Worker-4] INFO c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - There were no Online Payroll users found in memory to sync and update. 08:40:00.018 [DefaultQuartzScheduler_Worker-4] DEBUG c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - Exiting syncUsers. 08:40:00.018 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Entering getAllActiveBMUsers. 08:40:00.018 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - Entering isEmpty. 08:40:00.018 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - User Map is empty: true 08:40:00.018 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - Exiting isEmpty. 08:40:00.018 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Exiting getAllActiveBMUsers. 08:40:00.019 [DefaultQuartzScheduler_Worker-3] INFO c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - There were no Billing Manager users found in memory to sync and update. 08:40:00.019 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Exiting syncUsers. ò [akma4116@nova1a-qa:/opt/jboss/sbfw-V2.0.0-onlineserv-home/server/default/log]$ tail -f server.log 07:47:43.812 [Thread-30] DEBUG c.d.s.i.dao.slave.broker.Response [->00070:root] - Reading response input stream HEADER portion. 07:47:43.813 [Thread-29] DEBUG c.d.s.i.d.s.client.DIISBrokerAccess [->00070:root] - Received DIIS response: DIISMessage{messageContent=<RSP>LOGMESSAGE<RC>0<OK> ---LOGGED entry OK---<TMHOST>19, messageId=00000000, validateHeader=true, isValidHeader=true} 07:47:43.813 [Thread-29] DEBUG c.d.s.i.dao.slave.diis.DIISLexer [->00070:root] - instantiated DIISLexer 07:47:43.813 [Thread-29] DEBUG c.d.s.i.dao.slave.diis.DIISParser [->00070:root] - constructor 07:47:43.813 [Thread-29] DEBUG c.d.s.i.logging.IAALogHandler [->00070:root] - Successfully published to the IAALog ò [akma4116@nova1a-qa:/opt/jboss/sbfw-V2.0.0-onlineserv-home/server/default/log]$ tail -f server.2009-07-06.log 08:50:00.098 [DefaultQuartzScheduler_Worker-4] DEBUG c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - Exiting getAllPendingIOPUsers. 08:50:00.098 [DefaultQuartzScheduler_Worker-4] INFO c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - There were no Online Payroll users found in memory to sync and update. 08:50:00.098 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Entering getAllActiveBMUsers. 08:50:00.098 [DefaultQuartzScheduler_Worker-4] DEBUG c.i.s.c.s.UpdateOnlinePayrollUserStatusJob [->:] - Exiting syncUsers. 08:50:00.098 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - Entering isEmpty. 08:50:00.098 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - User Map is empty: true 08:50:00.098 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserMap [->:] - Exiting isEmpty. 08:50:00.098 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Exiting getAllActiveBMUsers. 08:50:00.098 [DefaultQuartzScheduler_Worker-3] INFO c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - There were no Billing Manager users found in memory to sync and update. 08:50:00.099 [DefaultQuartzScheduler_Worker-3] DEBUG c.i.s.c.s.UpdateBillingManagerUserStatusJob [->:] - Exiting syncUsers. -- 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 11

[JIRA] Created: (LBCLASSIC-145) SocketAppender is omitting CallerData.
by Joern Huxhorn (JIRA) 10 Aug '09

10 Aug '09

SocketAppender is omitting CallerData. -------------------------------------- Key: LBCLASSIC-145 URL: http://jira.qos.ch/browse/LBCLASSIC-145 Project: logback-classic Issue Type: Bug Components: appender Affects Versions: 0.9.16 Reporter: Joern Huxhorn Assignee: Logback dev list LoggingEventVO is never assigning a value to callerDataArray so the caller data is omitted regardless of the value of SocketAppenders includeCallerData property. As far as I can tell, this should probably be implemented in LoggingEventVO build(ILoggingEvent le) like this: if(le.hasCallerData()) { ledo.callerData = le.getCallerData(); } I'm unsure where the caller data should be obtained, though. LoggingEventPreSerializationTransformer will probably need an includeCallerData property that's initialized whenever the setIncludeCallerData of SocketAppender is called. It could then execute getCallerData(), if requested, before calling build. -- 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: (LBCORE-91) Add new TriggeringPolicy class to cause one rollover at the start of each run
by Rick Beton (JIRA) 09 Aug '09

09 Aug '09

Add new TriggeringPolicy class to cause one rollover at the start of each run ----------------------------------------------------------------------------- Key: LBCORE-91 URL: http://jira.qos.ch/browse/LBCORE-91 Project: logback-core Issue Type: New Feature Components: Appender Affects Versions: 0.9.15 Environment: - Reporter: Rick Beton Assignee: Logback dev list Priority: Minor A new TriggeringPolicy will cause the logfile to rollover once at startup when used with FixedWindowRollingPolicy. This is useful during development so that the logfiles of recent runs are still available. Here is a candidate implementation. Note that * <append>true</append> is required - otherwise the previous file is overwritten before rollover happens, so rollover results in a useless list of empty files. * the documentation would need to warn users of the effect of running multiple applications concurrently (i.e. concurrent operating system processes) with the same logfiles. This applies even without the suggested feature. package ch.qos.logback.core.rolling; import java.io.File; import ch.qos.logback.core.rolling.TriggeringPolicyBase; /** * SimpleStartupTriggeringPolicy triggers a rollover once at startup only. This * is useful for preserving older logfiles during development. * * @author Rick Beton */ public final class SimpleStartupTriggeringPolicy<E> extends TriggeringPolicyBase<E> { private boolean fired = false; public SimpleStartupTriggeringPolicy () { // does nothing } public boolean isTriggeringEvent( final File activeFile, final E event ) { final boolean result = !fired && (activeFile.length() > 0); fired = true; if (result) { addInfo( "Triggering rollover for " + activeFile ); } return result; } } -- 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 4