- logback-user - mailman3.qos.ch

SecurityManager issue using logback
by Andrew Bourgeois 06 Nov '11

06 Nov '11

Hello Ceki said my “bug” report isn’t actually a bug, but didn’t have the tell to tell me what’s wrong: http://jira.qos.ch/browse/LBCLASSIC-304 Can anyone here help? In short: package be.removed.fun.removed; import java.rmi.RMISecurityManager; import org.slf4j.Logger; import org.slf4j.LoggerFactory; public class TestMain { private static final Logger logger = LoggerFactory.getLogger(TestMain.class); public static void main(String[] args) throws Exception { System.setProperty("java.security.policy", "./src/main/config/java.policy"); logger.debug("Policy location: {}", System.getProperty("java.security.policy")); if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } System.setProperty("java.security.policy", "./src/main/config/java.policy"); } } ...runs fine using log4j: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>log4j</groupId> <artifactId>log4j</artifactId> <version>1.2.16</version> </dependency> <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-log4j12</artifactId> <version>1.6.0</version> </dependency> ...and gives an exception when switching to logback: <dependency> <groupId>org.slf4j</groupId> <artifactId>slf4j-api</artifactId> <version>1.6.0</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-core</artifactId> <version>1.0.0</version> </dependency> <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>1.0.0</version> </dependency> The exception is thrown at the last line of the main: 01:05:37.702 [main] DEBUG be.removed.fun.removed.TestMain - Policy location: ./src/main/config/java.policy Exception in thread "main" java.security.AccessControlException: access denied (java.util.PropertyPermission java.security.policy write) at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) at java.security.AccessController.checkPermission(AccessController.java:546) at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) at java.lang.System.setProperty(System.java:725) at be.removed.fun.removed.TestMain.main(TestMain.java:18) The policy file is: grant { permission java.security.AllPermission; }; The problem gets fixed if I put this file into: $JAVA_HOME/jre/lib/security Thank you for your time! Best regards Andrew Bourgeois

4 13

Encoder pattern documentation?
by Andrew Bourgeois 06 Nov '11

06 Nov '11

Hello again can I find a complete documentation somewhere describing the “pattern” property of encoder? There are a few examples inside the documentation, but none of them are really exhaustive. I was surprised to see the output of: pattern = "%d{yyyy-MM-dd HH:mm:ss,SSS} [%t] %-5p - (%c) - %m%n" which wasn’t converted by the tools available (from my log4j.properties). Also... while it’s kind of obvious, I couldn’t find a sentence saying “for the Groovy configuration you need ‘groovy-1.8.3.jar’ on your classpath”. The only thing I found was: “GEventEvaluator depends on the Groovy runtime. It was tested with Groovy version 1.7.2. ” (source: http://logback.qos.ch/setup.html ). I may also have missed the page explaining it all, let me know if I did. Thank you for your time! Best regards Andrew Bourgeois

2 2

log4j to logback question
by Steve Cohen 06 Nov '11

06 Nov '11

how would I replace log4j's LoggingEvent.getLocationInformation() in logback?

3 3

Re: [logback-user] SecurityManager issue using logback
by Andrew Bourgeois 05 Nov '11

05 Nov '11

Ceki, actually, a third option is not to use System.setProperty(...) for java.security.policy, but pass it as a parameter when launching the app (-Djava.security.policy=java.policy). FYI: I only use System.setProperty(...) for small systests that I launch from my IDE. Best regards Andrew Bourgeois -----Original Message----- From: Andrew Bourgeois Sent: Saturday, November 05, 2011 5:28 PM To: logback users list Subject: Re: [logback-user] SecurityManager issue using logback Ceki, you're right, I do get the exception when executing that block of code. I have 2 workarounds for my problem: 1) Put the java.policy file into $JAVA_HOME/jre/lib/security: That's too dirty, I'll skip this one. 2) Initialize the security manager before initializing logback: @Test public void loggingAfterSecurityManager() { System.setProperty("java.security.policy", "./src/test/resources/java.policy"); if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); logger.debug("Policy location: {}", System.getProperty("java.security.policy")); System.setProperty("java.security.policy", "./src/test/resources/java.policy"); } The test passes because I did what I had to do before loading the logback classes. The following doesn't pass: @Test public void loggingBeforeSecurityManager() { Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); logger.debug("Policy location: {}", System.getProperty("java.security.policy")); System.setProperty("java.security.policy", "./src/test/resources/java.policy"); if (System.getSecurityManager() == null) { System.setSecurityManager(new RMISecurityManager()); } logger.debug("Policy location: {}", System.getProperty("java.security.policy")); } If I dare to initialize logback before initializing a security manager, once I do it, it all goes wrong with code that uses the SecurityManager (so the last logger.debug(...) fails!). I'm not an expert so I can't say it's bad, but it's annoying. Thank you for your help! Best regards Andrew Bourgeois -----Original Message----- From: ceki Sent: Saturday, November 05, 2011 4:25 PM To: logback users list Subject: Re: [logback-user] SecurityManager issue using logback Thanks for the sample project. I can confirm that I observe a AccessControlException when logback is present. The AccessControlException is not thrown if slf4j-nop, slf4j-simple or slf4j-log4j are used as the slf4j binding. Although logback does not install its own SecurityManager or modify the security configuration, it does attempt to determine whether it has "getClassLoader" permission. See http://goo.gl/zASBm Here is the code in question: AccessController.doPrivileged(new PrivilegedAction<Boolean>() { public Boolean run() { try { AccessController.checkPermission( new RuntimePermission("getClassLoader")); return true; } catch (AccessControlException e) { return false; } } }); If the privileged block above code is removed, then the AccessControlException goes away. The privileged block looks quite legitimate to me so I don't think it's a bug in logback. To convince yourself the the privileged block is key, you can remove all logging related calls and all logging related dependencies, add the privileged block at the beginning of the test. You should observe an AccessControlException being thrown. -- Ceki http://twitter.com/#!/ceki On 11/5/2011 1:42 PM, Andrew Bourgeois wrote: > Ceki, > > I redid the test in a clean Maven project. I don't know if attachments > will pass through, so: > > 1) pom.xml: > > <project xmlns="http://maven.apache.org/POM/4.0.0" > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd"> > <modelVersion>4.0.0</modelVersion> > <name>test</name> > <groupId>be.test.fun</groupId> > <artifactId>test</artifactId> > <version>0.1.0-RC1</version> > <dependencies> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-api</artifactId> > <version>1.6.0</version> > </dependency> > > <dependency> > <groupId>log4j</groupId> > <artifactId>log4j</artifactId> > <version>1.2.16</version> > </dependency> > <dependency> > <groupId>org.slf4j</groupId> > <artifactId>slf4j-log4j12</artifactId> > <version>1.6.0</version> > </dependency> > >  > > <dependency> > <groupId>junit</groupId> > <artifactId>junit</artifactId> > <version>4.4</version> > <scope>test</scope> > </dependency> > </dependencies> > <build> > <resources> > </resources> > <plugins> > <plugin> > <artifactId>maven-compiler-plugin</artifactId> > <configuration> > <source>1.6</source> > <target>1.6</target> > <verbose>true</verbose> > </configuration> > </plugin> > </plugins> > </build> > </project> > > 2) The JUnit test: > > package be.test.fun; > > import org.junit.Test; > import java.rmi.RMISecurityManager; > import org.slf4j.Logger; > import org.slf4j.LoggerFactory; > > public class SecurityManagerTest { > > @Test > public void securityManagerWithLogs() { > Logger logger = LoggerFactory.getLogger(SecurityManagerTest.class); > > System.setProperty("java.security.policy", > "./src/test/resources/java.policy"); > logger.debug("Policy location: {}", > System.getProperty("java.security.policy")); > if (System.getSecurityManager() == null) { > System.setSecurityManager(new RMISecurityManager()); > } > System.setProperty("java.security.policy", > "./src/test/resources/java.policy"); > } > > // @Test > // public void securityManagerWithoutLogs() { > // System.setProperty("java.security.policy", > "./src/test/resources/java.policy"); > // if (System.getSecurityManager() == null) { > // System.setSecurityManager(new RMISecurityManager()); > // } > // System.setProperty("java.security.policy", > "./src/test/resources/java.policy"); > // } > } > > 3) java.policy that you put into src/test.resources: > > grant { > permission java.security.AllPermission; > }; > > So.... if you run this: > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running be.test.fun.SecurityManagerTest > 2011-11-05 13:36:33,828 [main] DEBUG - (be.test.fun.SecurityManagerTest) > - Policy location: ./src/test/resources/java.policy > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.201 sec > > Results : > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > > Now, comment the 2 LOG4J-related dependencies inside the POM, and > uncomment the logback ones: > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running be.test.fun.SecurityManagerTest > 13:38:04.222 [main] DEBUG be.test.fun.SecurityManagerTest - Policy > location: ./src/test/resources/java.policy > java.security.AccessControlException: access denied > (java.lang.RuntimePermission setContextClassLoader) > at > java.security.AccessControlContext.checkPermission(AccessControlContext.java:323) > > at > java.security.AccessController.checkPermission(AccessController.java:546) > at java.lang.SecurityManager.checkPermission(SecurityManager.java:532) > at java.lang.Thread.setContextClassLoader(Thread.java:1394) > at > org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:366) > > at > org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021) > > [INFO] > ------------------------------------------------------------------------ > [INFO] BUILD FAILURE > [INFO] > ------------------------------------------------------------------------ > [INFO] Total time: 2.202s > > And now comment the "securityManagerWithLogs" test method, and uncomment > the "securityManagerWithoutLogs" one: > ------------------------------------------------------- > T E S T S > ------------------------------------------------------- > Running be.test.fun.SecurityManagerTest > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.105 sec > > Results : > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0 > > Do you have the same output? > > FYI: > > [xvepak@localhost test]$ mvn -version > Apache Maven 3.0.1 (r1038046; 2010-11-23 11:58:32+0100) > Java version: 1.6.0_23 > Java home: /home/xvepak/software/jdk1.6.0_23/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux" version: "2.6.18-238.12.1.el5" arch: "i386" Family: > "unix" > > Thank you for trying to help out!! > > Best regards > > Andrew Bourgeois > > -----Original Message----- From: ceki > Sent: Saturday, November 05, 2011 1:03 AM > To: logback users list > Subject: Re: [logback-user] SecurityManager issue using logback > > On 05/11/2011 12:47 PM, Andrew Bourgeois wrote: > >> So to reformulate: >> The exception IS thrown when we have SLF4J code >> The exception ISN'T thrown when we remove the SLF4J. > > That's not what I observe. An exception is thrown in both cases. _______________________________________________ Logback-user mailing list Logback-user(a)qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user

1 0

scanning property files that are read from configuration file
by Yoel Spotts 04 Nov '11

04 Nov '11

As described in the manual, one can set logback so that the logback config file is scanned for modifications by including the scan attribute on the <configuration> tag. However, if a property file is defined for property substitution with the <property> tag, that property file is NOT scanned for modifications. Is it possible to set up the property file to be scanned for changes? If not, can I make a feature request to add this ability - maybe add a "scan" attribute to the <property> tag which would add the property file to the Config watcher list. Thanks! Yoel Spotts | Senior Software Engineer | nexidia<http://www.nexidia.com/> | O: 404.495.7220 x4007 | [cid:image001.png@01CC9ADD.93791E20] <http://twitter.com/Nexidia> [cid:image002.png@01CC9ADD.93791E20] <http://www.linkedin.com/companies/nexidia> [cid:image003.png@01CC9ADD.93791E20] <http://www.youtube.com/user/NexidiaTV>

2 3

Log Rotation Fails on Windows if Using JNDI
by Scott Dudley 04 Nov '11

04 Nov '11

I just discovered that log rotation fails on Windows if using ContextJNDISelector. I've tried both FixedWindowRollingPolicy and TimeBasedRollingPolicy with the same outcome. If I disable JNDI, I lose the contextName but rotation occurs as expected. Here's the error I get: 12:22:36,006 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [c:\telmast6\soft\apache-tomcat-6.0.24\logs\debug.log] to [c:\telmast6\soft\apache-tomcat-6.0.24\logs\debug1.log] 12:22:36,006 |-WARN in c.q.l.co.rolling.helper.RenameUtil - Failed to rename file [c:\telmast6\soft\apache-tomcat-6.0.24\logs\debug.log] to [c:\telmast6\soft\apache-tomcat-6.0.24\logs\debug1.log]. 12:22:36,006 |-WARN in c.q.l.co.rolling.helper.RenameUtil - Please consider leaving the [file] option of RollingFileAppender empty. 12:22:36,006 |-WARN in c.q.l.co.rolling.helper.RenameUtil - See also http://logback.qos.ch/codes.html#renamingError And here is my logback.xml file: <configuration scan="true" scanPeriod="30 seconds"> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>${catalina.home}/logs/debug.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>${catalina.home}/logs/debug%i.log</fileNamePattern> <minIndex>1</minIndex> <maxIndex>5</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>25MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d{MM/dd HH:mm:ss.SSS}|%thread|%X{sessionUserName}|%-5level|%X{debugLevel}|%logger{36}|%replace(%msg){'\n', '~~~'}|%contextName%n</pattern> </encoder> </appender> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration> The logback and slf4j resources must be loaded by the servlet container classloader (multiple reasons) and this is also desirable as we want to funnel all logging into a single file however, we also need to know which application generated the call - er go our use of JNDI (MDC wouldn't work). By the way, this is a Windows-only issue. Works splendidly on Linux. Thanks. -- Scott Dudley Senior Developer Telesoft Corp. | 1661 E. Camelback Rd., Suite 300 | Phoenix, AZ, 85016

2 16

AbstractMethodError in LogbackMDCAdapter
by Raccoonwao 04 Nov '11

04 Nov '11

Hi all, I am using logback 0.9.9 with activemq 5.5.1. Right after startup, the application always encounters an AbstractMethodException in LogbackMDCAdapter, which is firstly triggered by PooledTaskRunner (line 45). A snippet is provided as: public static void main(String[] args) { MDCAdapter l = StaticMDCBinder.SINGLETON.getMDCA(); Map m = l.getCopyOfContextMap(); // <-- got excpetion System.out.println("np error"); // never come to this line } Seems that the concrete class LogbackMDCAdapter implements MDCAdapter without implementing the defined method getCopyOfContextMap(). Any clues? Thanks, Hei

2 1

no applicable action for [dialectCode], current pattern is [[configuration][appender][connectionSource][dialectCode]]
by Jordan Blay 03 Nov '11

03 Nov '11

Hi! I am getting the following errors in the log: 1. ERROR in ch.qos.logback.core.joran.spi.Interpreter@13:17 - no applicable action for [dialectCode], current pattern is [[configuration][appender][connectionSource][dialectCode]] 2. ERROR in ch.qos.logback.core.joran.spi.Interpreter@40:29 - no applicable action for [priority], current pattern is [[configuration][root][priority]] My configuration is like this: <appender name="db" class="ch.qos.logback.classic.db.DBAppender"> <connectionSource class="ch.qos.logback.core.db.DataSourceConnectionSource"> <dataSource class="com.mchange.v2.c3p0.ComboPooledDataSource"> <driverClass>com.mysql.jdbc.Driver</driverClass> <jdbcUrl>jdbc:mysql://localhost/mydb</jdbcUrl> <user>myuser</user> <password>mypass</password> </dataSource> <dialectCode>MYSQL_DIALECT</dialectCode> </connectionSource> </appender> I am using version 1.0.0 -- View this message in context: http://old.nabble.com/no-applicable-action-for--dialectCode-%2C-current-pat… Sent from the Logback User mailing list archive at Nabble.com.

2 1

Date instead of timestamp in dbappender
by Jordan Blay 03 Nov '11

03 Nov '11

Is there a way in dbappender, that timestamp field in logging_event will be a real date instead of int? -- View this message in context: http://old.nabble.com/Date-instead-of-timestamp-in-dbappender-tp32774133p32… Sent from the Logback User mailing list archive at Nabble.com.

3 2

Release of logback version 1.0.0
by ceki 01 Nov '11

01 Nov '11

Hello all, After only 6 years of gestation, I am happy to announce the release of logback version 1.0.0. It should hit the Maven central repository within the next 24 hours. There are no big changes in this release. None. No spectacular new features, no breakages. There are bug fixes and small enhancements but nothing earth shattering. The version number is bumped to 1.0.0 but otherwise things remain the same. Please refer to the news page for precise details of this release. http://logback.qos.ch/news.html You can download logback, including full source code, class files and documentation on our download page, shown below. http://logback.qos.ch/download.html You can receive logback related announcements by subscribing to the QOS.ch announce mailing list. To subscribe to QOS.ch announce list, please visit the following URL. http://www.qos.ch/mailman/listinfo/announce Enjoy, -- Ceki http://twitter.com/#!/ceki

4 4