- logback-user - mailman3.qos.ch

Log file permissions
by Hontvári József 08 Mar '10

08 Mar '10

I cannot discover why the log file created by logback has different permissions then another file created by the same Java process. I don't see anything special in Logback code, do I miss something? The log file is only readable by the user running the process. /var/lib/jddclient drwxr-s--- 2 jddclient adm 4096 2010-03-08 12:24 . drwxr-xr-x 58 root root 4096 2010-03-08 12:23 .. -rw-r--r-- 1 jddclient adm 103 2010-03-08 13:04 status.xml /var/log/jddclient drwxr-s--- 2 jddclient adm 4096 2010-03-08 12:24 . drwxr-xr-x 15 root root 4096 2010-03-08 12:25 .. -rw------- 1 jddclient adm 9811 2010-03-08 13:04 jddclient

2 2

filtering by logger name in logback console plugin
by Kearney, Joe 08 Mar '10

08 Mar '10

Hi, I'm trying to use the Logback Eclipse plugin, Eclipse 3.5.2, Logback Console plugin 1.1.0. Works a charm, until I try to write any more sophisticated filters than the only example of Level >= INFO and similar. I'm trying to filter to accept DEBUG messages from my code, but deny such messages from Spring, whose loggers are called "org.springframework...". I try the following and keep getting "The new expression is not correct." There is no error in the Eclipse error log or in the console. logger.contains("org.springframework") event.getLoggerName().contains("org.springframework") (Guessing types of these supplied variables from http://logback.qos.ch/manual/filters.html#evalutatorFilter.) Filtering on the message appears to be accepted by the config window: message.contains("org.springframework") But it doesn't apply any filtering to the logger name. (Here the logger name actually gets compacted to "o.s...." but trying other, non-compacted, segments of the name doesn't help either.) For now I can filter out things like "reating instance" or "bean", but that's hardly satisfactory. What am I doing wrong with the logger name/event? Thanks, Joe

2 3

Spawning threads w/ their own appender
by Al Bupp 06 Mar '10

06 Mar '10

Greetings Fellow Logback Users, I hoping that someone on this list can help me to understand why I'm seeing odd logging behavior in a servlet-based app I've written. No doubt I've mis-implemented some aspect of logback, but I don't know what it might be. Here's what I've got in braod strokes. A servlet app which accepts HTTP requests. The servlet contains some global configuration and app data, including backend DB credentials. The servlet has a logback appender defined in a xml file: <configuration> <appender name="CostingServlet" class="ch.qos.logback.core.rolling.RollingFileAppender">  <File>\\pusehk08\pvcost_devl$\costingservlet.log</File> <layout class="ch.qos.logback.classic.PatternLayout"> <Pattern>%-17d{yyyy-MMM-dd HH:mm} %-6r [%t] %-6p %c{3} - %m%n</Pattern> </layout> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <maxIndex>10</maxIndex> <FileNamePattern>\\pusehk08\pvcost_devl$\costingservlet.log.%i</FileNamePattern> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <MaxFileSize>2MB</MaxFileSize> </triggeringPolicy> </appender> <root level="debug"> <appender-ref ref="CostingServlet"/> </root> </configuration> I have to deploy this servlet to a series of dev, test and prod servers all using the same identical WAR package, so there are actually 3 different xml files, a particular one of which gets loaded depending on the state of a runtime server variable. I load the specific config file when the servlet inializes using this java code: <code> protected void configLogger() { // set logging configuration LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); lc.reset(); configurator.doConfigure(logConfigFullPath.toString()); } catch (JoranException je) { StringBuffer errMsg = new StringBuffer(outAppName.toString()); errMsg.append("Error loading logging configuration file: "); errMsg.append(je.toString()); System.out.println(errMsg.toString()); je.printStackTrace(); } } </code> As a result of incoming HTTP requests the servlet starts a thread to handle the request. This request handling class needs to have logging to a separate log file for each request. Since the logs for the requests should be named uniquely, I use the following xml configuration: <configuration> <timestamp key="byMilliSecond" datePattern="yyyyMMMdd'T'HHmmssSSSS" /> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <File>\\pusehk08\pvcost_devl$\reqlog-${byMilliSecond}.log</File> <layout> <Pattern>%-17d{yyyy-MMM-dd HH:mm} %-6r [%t] %-6p %c{3} - %m%n</Pattern> </layout> </appender> <root level="debug"> <appender-ref ref="FILE" /> </root> </configuration> Again, there have to be 3 separate request logging config files, one for each runtime environment. In the request handling class I also invoke the manual configuration: <code> LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); lc.reset(); configurator.doConfigure(reqLogConfigPath); } </code> The problem is that this approach doesn't work too well because after configuring the request logger, the servlet log message end up going into the request log until recall its configLogger() method. Seems like I'm missing something here, probably something hiding in plain sight in the manual. Any insight into this will be greatly appreciated. Cheers, Al -- View this message in context: http://old.nabble.com/Spawning-threads-w--their-own-appender-tp27772903p277… Sent from the Logback User mailing list archive at Nabble.com.

1 0

Help Logback and postgreSQL
by Mohammad Haider 05 Mar '10

05 Mar '10

Hi, I have created three tables for logback according to documentation. I have the following config. file: <?xml version="1.0" encoding="UTF-8"?> <configuration debug="true" scan="true" scanPeriod="30 seconds"> <appender name="DB" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource"> <driverClass>org.postgresql.Driver</driverClass> <url>jdbc:postgresql://localhost:5432/tips_log</url> <user>postgres</user> <password>test</password> </connectionSource> </appender> <root level="debug"> <appender-ref ref="DB"/> </root> </configuration> In my code I have put simple logger.debug("DB test");. However, I did not see any log data in the tables. Can anyone please help about this issue? Why am I not getting any log data in the table? -- Thanks * Mohammad Firoj Haider*

3 10

Servername in SocketAppender
by Ingo Siebert 05 Mar '10

05 Mar '10

Hi, I want to use the SocketAppender to collect log messages from more than one application server. It general it works fine, but I'm missing the servername or IP address of the server who sent the LoggingEvent. That means I need a layout like this: %date %servername %m%n In the documentation, I see a SocketAppender property called IncludeCallerData. But in the example it only prints %file and %line. What is the best practise to add the name/IP of the server which sent the logging event to the remote SimpleSocketServer? Best regards, Ingo

2 2

Re: [logback-user] Separating the logging-output of libraries in tomcat/shared
by toxel 05 Mar '10

05 Mar '10

Hello I have a little question when I use configuration bellow I take Exception Caused by: java.lang.UnsupportedOperationException: Key cannot be set. Using fixed key contextName at at *.logging.JNDIBasedContextDiscriminator.setKey(JNDIBasedContextDiscriminator.java:57) Maybe I need other configuration ? Ceki Gulcu wrote: > > > I think the short answer is yes. The nested appenders will have the > same configuration differentiated by the value returned by the > discriminator. You could add properties to the logger context and > since logger context properties are seen as variables, you could in > principle use the value of the property to filter events. Here is an > example using a ThresholdFilter and the variable myLevel with a > default substitution value (see [1]). > > <appender name="SIFT" > class="ch.qos.logback.classic.sift.SiftingAppender"> > <discriminator > class="ch.qos.logback.classic.sift.JNDIBasedContextDiscriminator"> > <Key>context</Key> > <DefaultValue>unknown</DefaultValue> > </discriminator> > <sift> > <appender name="FILE-${context}" > class="ch.qos.logback.core.FileAppender"> > <File>${context}.log</File> > <Append>true</Append> > <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> > <level>${myLevel:-DEBUG}</level> > </filter> > <layout> > <pattern>%d [%thread] %level %mdc %logger{35} - > %msg%n</pattern> > </layout> > </appender> > </sift> > </appender> > > You could set the myLevel property at the start of each > application. Here is the sample code for web-app A: > > > LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); > lc.putProperty("myLevel", some level value as appropriate for web-app > A); > > For web-app B, the code is similar: > > LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); > lc.putProperty("myLevel", some level value as appropriate for web-app > B); > > You need to make sure that the "myLevel" property is set before the > logger context is configured which means that you need to override > default logback configuration by invoking joran directly. Search for > "Invoking JoranConfigurator directly" in [2]. The code then becomes: > > LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); > > JoranConfigurator configurator = new JoranConfigurator(); > configurator.setContext(lc); > // the context was probably already configured by default > configuration > // rules > lc.reset(); > lc.putProperty("myLevel", some level value as appropriate for the > web-app); > configurator.doConfigure(args[0]); > > HTH, > > [1] > http://logback.qos.ch/manual/configuration.html#defaultValuesForVariables > [2] http://logback.qos.ch/manual/configuration.html > > > On 02/03/2010 1:52 PM, Achim Wiedemann wrote: >> Hi Ceki, >> >> I just implemented your suggestion and it works like a charm. :) >> So it seems like there's a workaround for LBLCLASSIC-166 with your new >> discriminator-class now. Great work and thanks a lot! >> >> By the way: Is there any possibility to have different logging-levels >> for the nested appenders of a SiftingAppender? >> >> >> greetz, >> achim >> >> >> >> >> Ceki Gülcü schrieb: >>> You are right. ContextBasedDiscriminator will not help you because the >>> context name is retreived from the LoggingEvent which ultimately gets >>> its value from the calling logger. If the calling logger is attached >>> to the wrong context, ContextBasedDiscriminator will give you the >>> wrong context name. Sorry for misleading you. >>> >>> However, I've written a new discriminator which should work assuming >>> you have installed ContextJNDISelector as explained in >>> >>> http://logback.qos.ch/manual/loggingSeparation.html >>> >>> JNDIBasedContextDiscriminator can be found at >>> >>> >>> http://github.com/ceki/logback/blob/90e50c/logback-classic/src/main/java/ch… >>> >>> >>> or the same in tiny-speak >>> >>> http://tinyurl.com/yb6pdj2 >>> >>> Getting values from JNDIBasedContextDiscriminator, SiftingAppender >>> will get the correct context name and things should work much better. >>> Give it a try. >>> >>> >>> >>> On 01/03/2010 9:38 AM, Achim Wiedemann wrote: >>>> Hey Ceki, >>>> >>>> thanks for your fast reply. I tested your tip with the SiftingAppender, >>>> but couldn't see how this gets me further compared to the >>>> logging-separation described in Ch8 of the manual (separation via >>>> JNDIContextSelector). The problem is still the same: The context of the >>>> logger, once initialized, remains the same in shared libraries. Since >>>> SiftingAppender has to sieve based on some criteria (in my case the >>>> context), it also can't solve this issue. >>>> >>>> So I see, as you already stated, it's not possible to get this scenario >>>> to work. However, thanks for your time and all your work. >>>> >>>> >>>> greetz, >>>> achim >>>> >>>> >>>> Ceki Gulcu schrieb: >>>>> >>>>> Hello Achim, >>>>> >>>>> Thank you for your message. >>>>> >>>>> >>>>> The only way to solve this issue transparently and perfectly would be >>>>> to introduce another level of indirection inside loggers so that each >>>>> logger-shell somehow delegate work to an inner logger attached to the >>>>> appropriate context. This is quite a difficult problem technically and >>>>> would generate significant computational overhead. I don't see the >>>>> problem fixed via such indirection any time soon. Read, as a logback >>>>> user, don't expect this problem to be solved without a little work on >>>>> your side. >>>>> >>>>> As far as I can see, you have two options: >>>>> >>>>> 1) move shared classes whose loggers you care about to the web-app >>>>> (unshare them) >>>>> >>>>> If 1) is not an option, there is: >>>>> >>>>> 2) Use a single shared logback.xml file with separation done by >>>>> SiftingAppender [1] using the context as separation criteria [2]. In >>>>> conjunction with prudent mode of FileAppender, you will be able to >>>>> separate logging by context. >>>>> >>>>> Let me know if the above does not make sense. >>>>> >>>>> >>>>> [1] http://logback.qos.ch/manual/appenders.html#SiftingAppender >>>>> [2] >>>>> http://logback.qos.ch/xref/ch/qos/logback/classic/sift/ContextBasedDiscrimi… >>>>> >>>>> >>>>> >>>>> On 26.02.2010 08:21, Achim Wiedemann wrote: >>>>>> Hey everybody, >>>>>> >>>>>> just wanted to port our application from commons-logging / log4j to >>>>>> slf4j / logback. Unfortunately I stumbled upon some problems when >>>>>> separating the logging-output from different webapps (using the >>>>>> JNDIContextSelector). As long as you only use logging from classes >>>>>> inside the webapp, everything works fine. But as soon as you've got >>>>>> classes in tomcat/shared which use logging, you run into trouble: All >>>>>> logging output of the shared classes (e.g. Spring) are directed to >>>>>> the >>>>>> logger-context of the webapp which first loads the (shared) class. >>>>>> >>>>>> Example: Let's say you've got webbapp [A], webbapp [B], and Spring in >>>>>> tomcat/shared. Now both webapps use Spring. If webapp [B] first >>>>>> accesses >>>>>> any classes of Spring, all output of Spring will be directed to the >>>>>> log-file of [B], no matter from which webapp Spring is used. This is >>>>>> because static Logger references are used in Spring (which is >>>>>> commonplace) and are initialized with the context of webapp [B]. >>>>>> >>>>>> The issue is already described very well in the logback JIRA: >>>>>> http://jira.qos.ch/browse/LBCLASSIC-166 >>>>>> >>>>>> I wondered if anyone can make a suggestion how to deal with this. Any >>>>>> advice, tricks or magic is welcome. ;) >>>>>> >>>>>> >>>>>> Thanks a lot, >>>>>> Achim >>>>> _______________________________________________ >>>>> Logback-user mailing list >>>>> Logback-user(a)qos.ch >>>>> http://qos.ch/mailman/listinfo/logback-user >>>> _______________________________________________ >>>> Logback-user mailing list >>>> Logback-user(a)qos.ch >>>> http://qos.ch/mailman/listinfo/logback-user >>> >>> _______________________________________________ >>> Logback-user mailing list >>> Logback-user(a)qos.ch >>> http://qos.ch/mailman/listinfo/logback-user >> >> _______________________________________________ >> Logback-user mailing list >> Logback-user(a)qos.ch >> http://qos.ch/mailman/listinfo/logback-user > > _______________________________________________ > Logback-user mailing list > Logback-user(a)qos.ch > http://qos.ch/mailman/listinfo/logback-user > > -- View this message in context: http://old.nabble.com/Separating-the-logging-output-of-libraries-in-tomcat-… Sent from the Logback User mailing list archive at Nabble.com.

2 11

Logback does not insert any log data into the database
by Mohammad Firoj Haider 04 Mar '10

04 Mar '10

Hi I am using PostgreSQL. and I have three tables for logback according to doc. However, I did not see any log data on the table. I am not getting any error either. I just copied logback doc example and I added my postgresql driver, username, password, database name and host. -- Thanks Mohammad Firoj Haider

1 0

Separating the logging-output of libraries in tomcat/shared
by Achim Wiedemann 02 Mar '10

02 Mar '10

Hey everybody, just wanted to port our application from commons-logging / log4j to slf4j / logback. Unfortunately I stumbled upon some problems when separating the logging-output from different webapps (using the JNDIContextSelector). As long as you only use logging from classes inside the webapp, everything works fine. But as soon as you've got classes in tomcat/shared which use logging, you run into trouble: All logging output of the shared classes (e.g. Spring) are directed to the logger-context of the webapp which first loads the (shared) class. Example: Let's say you've got webbapp [A], webbapp [B], and Spring in tomcat/shared. Now both webapps use Spring. If webapp [B] first accesses any classes of Spring, all output of Spring will be directed to the log-file of [B], no matter from which webapp Spring is used. This is because static Logger references are used in Spring (which is commonplace) and are initialized with the context of webapp [B]. The issue is already described very well in the logback JIRA: http://jira.qos.ch/browse/LBCLASSIC-166 I wondered if anyone can make a suggestion how to deal with this. Any advice, tricks or magic is welcome. ;) Thanks a lot, Achim

4 9

About DBAppender
by Mohammad Firoj Haider 28 Feb '10

28 Feb '10

Hi, I am new in Logback framework. I want to use mysql database to store my log. So I have set my logback-test.xml file in the following way: <?xml version="1.0" encoding="UTF-8"?> <configuration> <appender name="DB" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DriverManagerConnectionSource"> <driverClass>com.mysql.jdbc.Driver</driverClass> <url>jdbc:mysql://localhost:3306/testlogback</url> <user>root</user> <password>test</password> </connectionSource> </appender> <root level="debug"> <appender-ref ref="DB" /> </root> </configuration> After that I created a database which is called "testlogback". I have two simple java classes. The code snippet is: public class TestLogger { public static void main(String[] args){ Logger logger = LoggerFactory.getLogger("com.lashpoint.TestLogger"); LoggerContext lc=(LoggerContext) LoggerFactory.getILoggerFactory(); StatusPrinter.print(lc); logger.debug("Test start"); System.out.println("Hello World Logback"); SalaryTestLogger test=new SalaryTestLogger (); test.setHour(0); test.setSalary(100); System.out.println("Division: "+test.getSalary()); logger.debug("Test end"); } } public class SalaryTestLogger { ............................ public SalaryTestLogger(){ logger=LoggerFactory.getLogger("com.lashpoint.SalaryTestLogger "); } ................ .......................... } After running the code, I got the following output (However, I put StatusPrinter.print(lc) to see internal state). Driver name=MySQL-AB JDBC Driver Driver version=mysql-connector-java-5.0.7 ( $Date: 2007-03-09 22:13:57 +0100 (Fri, 09 Mar 2007) $, $Revision: 6341 $ ) supportsGetGeneratedKeys=true true 12:08:37,312 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/E:/DevTools/projects/Test/LogbackTest/src/com/lashpoint/logger/logback-test.xml] 12:08:37,421 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set 12:08:37,421 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.db.DBAppender] 12:08:37,437 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [DB] 12:08:37,468 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Pushing component [connectionSource] on top of the object stack. 12:08:37,812 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Popping appender named [DB] from the object stack 12:08:37,812 |-INFO in ch.qos.logback.classic.joran.action.RootLoggerAction - Setting level of ROOT logger to DEBUG 12:08:37,812 |-INFO in ch.qos.logback.core.joran.action.AppenderRefAction - Attaching appender named [DB] to Logger[ROOT] Hello World Logback Salry Per Hour: 0.0 The MOST INTERESTING THING is that, it did not log anything to logging_event, logging_event_exception, logging_event_property tables. So I think I am missing something. I would be glad if someone kindly help me to solve this issue. -- Thanks Mohammad Firoj Haider

1 0

(no subject)
by Gilles Gaillard 23 Feb '10

23 Feb '10

Hi, I'm new to logback and would like to know if the following already exist / is possible, i searched the mailing list but did not find this. I've a GUI application performing usual logging through logback (that's ok) and would ensure that any unexpected failure(s) be logged. For example, unexpected errors occuring on the swing EDT go the std err. Usually I would do this by redirecting the standard out/err streams to some file output. Note also that I would like to ensure that logs from different threads will log properly. For example, stack traces should not be mangled by other logs. I wonder it is possible to do this through the logback configuration. If not what would be the best way. Thanks, -- Gilles

4 5