I just checked the DN docs and was able to answer this (dumb) question
myself.

DN's logging can be configured using its logging categories.

On 13 Dez., 11:34, "a.maza" <andr.m...@gmail.com> wrote:
> 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.FinalizableRef­­erenceQueue">
> >         <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 -- 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.


Reply via email to