I'm using slf4j and logback, and the slf4j adapters for jakarta commons logging
etc., that re-route things through slf4j. Here's my maven "dependency pom" so
you can see what I'm using. After that is my logback.xml file (everything goes
to the console). If you're using maven, be sure and do a "mvn dependency:tree"
to make sure that you've successfully excluded jakarta commons logging.
<?xml version="1.0" encoding="ISO-8859-1" ?>
<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>
<groupId>com.objecteffects</groupId>
<artifactId>dependencies-logging</artifactId>
<packaging>pom</packaging>
<name>logging dependencies</name>
<version>1.5.8</version>
<description>logging dependencies module</description>
<!--
with provided scope on commons logging you still need to
explicitly exclude jakarta commons logging from each package
that's using it. if you use the version 99.0-does-not-exist
hack, it pulls in an empty jar file. so, in a way, the
99.0-does-not-exist hack is safer, because you won't ever get
the real jakarta commons logging jar included when you miss a
package that needs the exclusion. but it adds an extra dependency.
-->
<dependencies>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
<!-- use provided scope on real JCL instead -->
<!-- <version>99.0-does-not-exist</version> -->
<version>1.1.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>commons-logging</groupId>
<artifactId>commons-logging-api</artifactId>
<!-- use provided scope on real JCL instead -->
<!-- <version>99.0-does-not-exist</version> -->
<version>1.1</version>
<scope>provided</scope>
</dependency>
<!-- the slf4j commons-logging replacement -->
<!-- if any package is using jakarta commons logging this will -->
<!-- re-route it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<!-- the slf4j log4j replacement. -->
<!-- if any package is using log4j this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<!-- the slf4j java.util.logging replacement. -->
<!-- if any package is using jul this will re-route -->
<!-- it through slf4j. -->
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jul-to-slf4j</artifactId>
<version>${version.slf4j}</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${version.slf4j}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>${version.logback}</version>
</dependency>
</dependencies>
<properties>
<version.logback>0.9.15</version.logback>
<version.slf4j>1.5.8</version.slf4j>
</properties>
</project>
<?xml version="1.0" encoding="UTF-8"?>
<configuration debug="true">
<appender class="ch.qos.logback.core.ConsoleAppender"
name="RootConsoleAppender">
<layout class="ch.qos.logback.classic.PatternLayout">
<pattern>%date{yyyy-MM-dd HH:mm:ss.SSS z}, %5level: [%thread]
%class.%method.%line: %message%n</pattern>
</layout>
</appender>
<logger name="org.springframework.beans">
<level
value="warn"
/>
</logger>
<logger name="org.springframework.transaction">
<level
value="debug"
/>
</logger>
<logger name="org.springframework.orm.jdo.JdoTransactionManager">
<level
value="debug"
/>
</logger>
<!--
<logger
name="com.google.appengine.repackaged.com.google.common.base.FinalizableReferenceQueue">
<level
value="warn"
/>
</logger>
-->
<logger name="com.objecteffects">
<level
value="debug"
/>
</logger>
<root>
<level
value="info"
/>
<appender-ref
ref="RootConsoleAppender"
/>
</root>
</configuration>
Philippe Marschall wrote:
>
> On Dec 12, 2:50 pm, "a.maza" <andr.m...@gmail.com> wrote:
>> Hello,
>>
>> I have currently some troubles with logging in junit tests. In
>> general, I have the following questions:
>>
>> -) According to the manuals, I could basically use any log framework
>> which logs to System.out and System.err, respectively (e.g., log4j).
>> However, for having a fine grained selection mechanism in the admin
>> console, the use of java.util.logging (JUL) is required. Is this true,
>> since the log levels of the admin console remind me rather to those of
>> log4j than those of JUL.
>>
>> -) JUL logging works quite fine for running the web application on
>> jetty. However, when doing junit tests, JUL does not automatically
>> read the logging.properties from the file system resulting in logging
>> INFO and above.
>> I have learned that the logging.properties file can be set using the -
>> Djava.util.logging.config.file jvm argument. However, doing this for
>> every junit test is a little bit cumbersome. (i.e., not an option).
>> Some websites state that setting a system property
>> (java.util.logging.config.file) in the base test class may work - but
>> not in my case.
>> JUL would allow to read a logging.properties file from the filesystem
>> using the LogManager class. However, the LogManager is a restricted
>> class on GAE (also in the dev environment).
>>
>> I also thought about the option of using SLF4J with the JUL binding
>> for the web application and SLF4J with a log4j binding for JUnit
>> tests... but I am not sure if this works out....
>
> Since SLF4J is just a facade it doesn't support any configuration.
>
>> I would be happy to hear from others how they manage logging
>> (especially in JUnit tests) or any suggestions that might help...
>
> I don't use JUL if I have a choice. With logback you can just add a
> logback-test.xml to src/test/resources and you're set. For JUL
> configuring argLine in the surefire plugin might be an option. You
> could also put a MethodRule or some setup method an abstract super
> class for all tests that set up JUL.
>
> Cheers
> Philippe
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Google App Engine for Java" group.
> To post to this group, send email to google-appengine-j...@googlegroups.com.
> To unsubscribe from this group, send email to
> google-appengine-java+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-appengine-java?hl=en.
>
>
--
You received this message because you are subscribed to the Google Groups
"Google App Engine for Java" group.
To post to this group, send email to google-appengine-j...@googlegroups.com.
To unsubscribe from this group, send email to
google-appengine-java+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
