thanks for your help. using logback for everything through the slf4j bridges is really an improvement.
I just a slight problem remaining: now datanucleus logs everything through org.datanucleus.util.Log4JLogger.debug.58: ... which does not allow for a fine-grained configuration. has anybody experienced the same problem and knows how to solve it? thanks On 12 Dez., 21:36, Rusty Wright <rwright.li...@gmail.com> wrote: > 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 > > athttp://groups.google.com/group/google-appengine-java?hl=en.- Zitierten > > Text ausblenden - > > - Zitierten Text anzeigen - -- 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.
