I have a spring application with the following logback config file:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<include resource="org/springframework/boot/logging/logback/base.xml"/>
<logger name="PAPERTRAIL_LOGGER" level="error" additivity="false">
<appender name="PAPERTRAIL" class="ch.qos.logback.classic.net.SyslogAppender">
<syslogHost>[HOST]</syslogHost>
<port>[PORT]</port>
<facility>user</facility>
<suffixPattern>[%d{yyyy-MM-dd HH:mm:ss.SSS}] %clr(%5p) KOCH --- %ex{full}</suffixPattern>
</appender>
</logger>
</configuration>
But when I send a log message with the following code:
LoggerFactory.getLogger("PAPERTRAIL_LOGGER").error("Error: ", throwable);
Spring is sending two set of messages, one formatted by the suffixPattern provided:
Jun 13 10:45:04 DEVLINUSCUA03 DEVLINUSCUA03 [2022-06-13 14:45:04.320] ERROR KOCH --- org.postgresql.util.PSQLException: ERROR: relation "forcederror" does not exist Position: 15 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2675) at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2365) [...]
and another broken in lines:
Jun 13 10:45:04 DEVLINUSCUA03 org.postgresql.util.PSQLException ERROR: relation "forcederror" does not exist Position: 15
Jun 13 10:45:04 DEVLINUSCUA03 at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:2675)
Jun 13 10:45:04 DEVLINUSCUA03 at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:2365)
Jun 13 10:45:04 DEVLINUSCUA03 at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:355)
Jun 13 10:45:04 DEVLINUSCUA03 at org.postgresql.jdbc.PgStatement.executeInternal(PgStatement.java:490)
[...]
How can I make it for spring to not send the second message to the syslog server?
Using your exact configuration (minus a postgres implementation) I get but a single log entry. I suspect that the postgres logger is doing this for you. Try disabling it and see what happens, then you can dive in to its configuration
<logger name="org.postgresql" level="OFF"/>`
I have created a sample application by following the tutorial mentioned at Creating a Basic REST Web Service using Grizzly, Jersey. I have extended the sample with logback.xml. I later found out that jersey uses java.util.logging and configured a slf4j bridge. Things are working fine but I get a unrecoverable exception when having logback level at trace and works fine when level is set at debug or higher (INFO, WARN etc).
Below is the stacktrace -
20:35:24.531 [grizzly-nio-kernel(7) SelectorRunner] WARN o.g.g.filterchain.DefaultFilterChain - GRIZZLY0013: Exception during FilterChain execution
java.lang.NullPointerException: null
at java.lang.String.<init>(String.java:166)
at java.lang.String.valueOf(String.java:3008)
at org.glassfish.grizzly.filterchain.FilterChainContext.toString(FilterChainContext.java:1076)
at java.text.MessageFormat.subformat(MessageFormat.java:1280)
at java.text.MessageFormat.format(MessageFormat.java:865)
at java.text.Format.format(Format.java:157)
at java.text.MessageFormat.format(MessageFormat.java:841)
at org.slf4j.bridge.SLF4JBridgeHandler.getMessageI18N(SLF4JBridgeHandler.java:265)
at org.slf4j.bridge.SLF4JBridgeHandler.callLocationAwareLogger(SLF4JBridgeHandler.java:220)
at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:303)
at java.util.logging.Logger.log(Logger.java:738)
at java.util.logging.Logger.doLog(Logger.java:765)
at java.util.logging.Logger.log(Logger.java:851)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeFilter(DefaultFilterChain.java:280)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.executeChainPart(DefaultFilterChain.java:201)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:133)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
at org.glassfish.grizzly.nio.NIOConnection.preClose(NIOConnection.java:879)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.preClose(TCPNIOConnection.java:97)
at org.glassfish.grizzly.nio.NIOConnection.terminate0(NIOConnection.java:603)
at org.glassfish.grizzly.nio.transport.TCPNIOConnection.terminate0(TCPNIOConnection.java:291)
at org.glassfish.grizzly.nio.NIOConnection$4.completed(NIOConnection.java:567)
at org.glassfish.grizzly.nio.NIOConnection$4.completed(NIOConnection.java:563)
at org.glassfish.grizzly.asyncqueue.AsyncWriteQueueRecord.notifyCompleteAndRecycle(AsyncWriteQueueRecord.java:173)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:279)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:169)
at org.glassfish.grizzly.nio.AbstractNIOAsyncQueueWriter.write(AbstractNIOAsyncQueueWriter.java:71)
at org.glassfish.grizzly.AbstractWriter.write(AbstractWriter.java:76)
at org.glassfish.grizzly.nio.NIOConnection.closeGracefully0(NIOConnection.java:562)
at org.glassfish.grizzly.nio.NIOConnection.closeWithReason(NIOConnection.java:513)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.execute(DefaultFilterChain.java:160)
at org.glassfish.grizzly.filterchain.DefaultFilterChain.process(DefaultFilterChain.java:112)
at org.glassfish.grizzly.ProcessorExecutor.execute(ProcessorExecutor.java:77)
at org.glassfish.grizzly.nio.transport.TCPNIOTransport.fireIOEvent(TCPNIOTransport.java:539)
at org.glassfish.grizzly.nio.transport.TCPNIOServerConnection$RegisterAcceptedChannelCompletionHandler.completed(TCPNIOServerConnection.java:353)
at org.glassfish.grizzly.nio.transport.TCPNIOServerConnection$RegisterAcceptedChannelCompletionHandler.completed(TCPNIOServerConnection.java:320)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.registerChannel0(DefaultSelectorHandler.java:336)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.access$400(DefaultSelectorHandler.java:64)
at org.glassfish.grizzly.nio.DefaultSelectorHandler$RegisterChannelOperation.run(DefaultSelectorHandler.java:467)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.processPendingTaskQueue(DefaultSelectorHandler.java:301)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.processPendingTasks(DefaultSelectorHandler.java:293)
at org.glassfish.grizzly.nio.DefaultSelectorHandler.preSelect(DefaultSelectorHandler.java:101)
at org.glassfish.grizzly.nio.SelectorRunner.doSelect(SelectorRunner.java:335)
at org.glassfish.grizzly.nio.SelectorRunner.run(SelectorRunner.java:279)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:593)
at org.glassfish.grizzly.threadpool.AbstractThreadPool$Worker.run(AbstractThreadPool.java:573)
at java.lang.Thread.run(Thread.java:748)
My logging.properties file -
handlers = org.slf4j.bridge.SLF4JBridgeHandler
.level=ALL
java.util.logging.SLF4JBridgeHandler.level = ALL
My logback.xml file -
<configuration>
<contextListener class="ch.qos.logback.classic.jul.LevelChangePropagator">
<resetJUL>true</resetJUL>
</contextListener>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<!-- encoders are assigned the type
ch.qos.logback.classic.encoder.PatternLayoutEncoder by default -->
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<root level="trace">
<appender-ref ref="STDOUT" />
</root>
</configuration>
NOTE: I have the following in my main method if it makes any difference
SLF4JBridgeHandler.removeHandlersForRootLogger();
SLF4JBridgeHandler.install();
This is bug FilterChainContext.toString crashes with NullPointerException #1959 in Grizzly.
There are two overloads of String.valueOf, with Object and char[]. (Java 8)
Because of the dangerous unbound generic in getMessage both overloads would seem applicable, however the char[] overload is chosen, probably because it is more specific.
[snip]
However String.valueOf(char[]) will fail if the result of getMessage is null. I would assume a ClassCastException could happen in other cases. This can be fixed by explicitly casting the result to object or ensuring that the correct generics are infered.
You need to upgrade to a newer version of Grizzly (2.4.3).
A regression bug was filed in Nov 10, 2020 under: FilterChainContext.toString causes NullPointerException #2110 which reports fixed in 4.0.0-M2-RELEASE.
Commit is listed as: https://github.com/eclipse-ee4j/grizzly/commit/d7a96f15083a55c38f63746007f664f1ede9f474
I am running some unit tests and I was to use SLF4J and logback.
Here is the relevant pom.xml
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-test</artifactId>
<version>4.2.6-RELEASE</version>
<exclusions>
<exclusion>
<groupId>commons-logging</groupId>
<artifactId>commons-logging</artifactId>
</exclusion>
</exclusions>
<scope>test</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>1.1.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>jcl-over-slf4j</artifactId>
<version>1.7.21</version>
</dependency>
And here is the log and stacktrace:
20:29:16,293 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback-test.xml] at [file:/code/web/target/test-classes/logback-test.xml]
20:29:16,387 |-ERROR in ch.qos.logback.core.joran.event.SaxEventRecorder#7a1ebcd8 - Unexpected exception while parsing XML document. java.lang.NullPointerException
at java.lang.NullPointerException
at at org.xml.sax.helpers.LocatorImpl.<init>(LocatorImpl.java:103)
at at ch.qos.logback.core.joran.event.SaxEvent.<init>(SaxEvent.java:31)
at at ch.qos.logback.core.joran.event.StartEvent.<init>(StartEvent.java:27)
at at ch.qos.logback.core.joran.event.SaxEventRecorder.startElement(SaxEventRecorder.java:106)
at at org.allcolor.xml.parser.CShaniSaxParser.parseStartTag(CShaniSaxParser.java:1393)
at at org.allcolor.xml.parser.CXmlParser.parseSTARTTag(CXmlParser.java:1405)
at at org.allcolor.xml.parser.CXmlParser.parse(CXmlParser.java:682)
at at org.allcolor.xml.parser.CShaniSaxParser.parse(CShaniSaxParser.java:767)
at at javax.xml.parsers.SAXParser.parse(SAXParser.java:392)
at at ch.qos.logback.core.joran.event.SaxEventRecorder.recordEvents(SaxEventRecorder.java:59)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:141)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:103)
at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
at at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
at at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
at at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55)
at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:155)
at at org.apache.commons.logging.impl.SLF4JLogFactory.getInstance(SLF4JLogFactory.java:132)
at at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:685)
at at org.springframework.test.context.junit4.SpringJUnit4ClassRunner.<clinit>(SpringJUnit4ClassRunner.java:91)
at at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at at java.lang.reflect.Constructor.newInstance(Constructor.java:422)
at at org.junit.internal.builders.AnnotatedBuilder.buildRunner(AnnotatedBuilder.java:104)
And the logback-test.xml:
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<appender name="consoleAppender" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<Pattern>.%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg %n
</Pattern>
</encoder>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>TRACE</level>
</filter>
</appender>
<root>
<level value="INFO" />
<appender-ref ref="consoleAppender" />
</root>
<logger name="com.me.ControllerTester" level="debug" additivity="false">
<appender-ref ref="consoleAppender" />
</logger>
</configuration>
Now I have checked the dependency tree, and I have nothing conflicting. I have tried messing with the SAX parser versions.
The XML looks fine to me. I must be conflicted somehow...
Any Ideas?
logback uses SAXParserFactory.newInstance(), which has a lookup procedure that determines which implementation to use. It seems that org.allcolor.xml.parser.CShaniSaxParser is being selected in your environment based on this lookup:
public static SAXParserFactory newInstance()
Obtain a new instance of a SAXParserFactory. This static method creates a new factory instance This method uses the following ordered lookup procedure to determine the SAXParserFactory implementation class to load:
Use the javax.xml.parsers.SAXParserFactory system property.
Use the properties file "lib/jaxp.properties" in the JRE directory. This configuration file is in standard java.util.Properties format and contains the fully qualified name of the implementation class with the key being the system property defined above. The jaxp.properties file is read only once by the JAXP implementation and it's values are then cached for future use. If the file does not exist when the first attempt is made to read from it, no further attempts are made to check for its existence. It is not possible to change the value of any property in jaxp.properties after it has been read for the first time.
Use the Services API (as detailed in the JAR specification), if available, to determine the classname. The Services API will look for a classname in the file META-INF/services/javax.xml.parsers.SAXParserFactory in jars available to the runtime.
Platform default SAXParserFactory instance.
Once an application has obtained a reference to a SAXParserFactory it can use the factory to configure and obtain parser instances.
Tip for Trouble-shooting
Setting the jaxp.debug system property will cause this method to print a lot of debug messages to System.err about what it is doing and where it is looking at.
If you have problems loading DocumentBuilders, try:
java -Djaxp.debug=1 YourProgram ....
Try switching to a standard SAX parser (such as Apache Xerces) by setting javax.xml.parsers.SAXParserFactory system property for your unit tests:
-Djavax.xml.parsers.SAXParserFactory=org.apache.xerces.jaxp.SAXParserFactoryImpl
I am new to spring and log4j.I am trying a sample Hello World project with spring framework and using log4j2 library. I have log4j2.xml in my src folder. When i run the application, only my application logs are written in the log file. The spring logs are not written.However i can see them in the console. I have commons logging jar (spring dependency), log4j2 and spring jars in my classpath. Can anyone help me if I am missing any configuration here?
My log4j2 xml file,
<?xml version="1.0" encoding="UTF-8"?>
<configuration status="trace" monitorInterval="5">
<Appenders>
<Console name="consoleAppender" target="SYSTEM_OUT">
<PatternLayout pattern="%d %-5p [%t] %C{2} (%F:%L) - %m%n"/>
</Console>
<File name="fileAppender" fileName="learning.log" append="true">
<PatternLayout pattern="%t %-5p %c{2} - %m%n"/>
</File>
</Appenders>
<Loggers>
<Root level="trace">
<AppenderRef ref="consoleAppender"/>
<AppenderRef ref="fileAppender"/>
</Root>
</Loggers>
</configuration>
My Code:
public class MainApp {
static Logger log = LogManager.getLogger(MainApp.class.getName());
public static void main(String[] args) {
ApplicationContext context =
new ClassPathXmlApplicationContext("Beans.xml");
log.info("Going to create HelloWord Obj");
HellowWorld obj = (HellowWorld) context.getBean("helloWorld");
obj.getMessage();
log.info("Exiting the program");
}
}
output:
main INFO springExample.MainApp - Going to create HelloWord Obj
main INFO springExample.MainApp - Exiting the program
The spring logs are missing in the output file.
Thanks,
Suma
Since the other answers don't spell it out in the actual answer, the solution is to add the Commons Logging Bridge dependency below to the Maven pom.xml file.
As stated on the Apache Log4j web page:
If existing components use Apache Commons Logging 1.x and you want to
have this logging routed to Log4j 2, then add the following but do not
remove any Commons Logging 1.x dependencies.
<dependencies>
...
<dependency>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>log4j-jcl</artifactId>
<version>2.1</version>
</dependency>
...
</dependencies>
See the example below of the effect of adding this dependency in:
Before:
May 11, 2015 8:10:41 PM org.springframework.context.support.ClassPathXmlApplicationContext prepareRefresh
INFO: Refreshing org.springframework.context.support.ClassPathXmlApplicationContext#300ffa5d: startup date [Mon May 11 20:10:41 IST 2015]; root of context hierarchy
May 11, 2015 8:10:42 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [datapower.xml]
May 11, 2015 8:10:42 PM org.springframework.ws.soap.saaj.SaajSoapMessageFactory afterPropertiesSet
INFO: Creating SAAJ 1.3 MessageFactory with SOAP 1.1 Protocol
May 11, 2015 8:10:42 PM org.springframework.oxm.jaxb.Jaxb2Marshaller createJaxbContextFromContextPath
INFO: Creating JAXBContext with context path [com.datapower.schemas.management]
May 11, 2015 8:10:45 PM org.springframework.oxm.jaxb.Jaxb2Marshaller createJaxbContextFromContextPath
INFO: Creating JAXBContext with context path [com.datapower.schemas.management]
May 11, 2015 8:10:47 PM org.springframework.ws.soap.saaj.SaajSoapMessageFactory afterPropertiesSet
INFO: Creating SAAJ 1.3 MessageFactory with SOAP 1.1 Protocol
After:
22:07:21.925 [main] INFO org.springframework.context.support.ClassPathXmlApplicationContext - Refreshing org.springframework.context.support.ClassPathXmlApplicationContext#22eeefeb: startup date [Mon May 11 22:07:21 IST 2015]; root of context hierarchy
22:07:21.950 [main] INFO org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Loading XML bean definitions from class path resource [datapower.xml]
22:07:22.059 [main] INFO org.springframework.ws.soap.saaj.SaajSoapMessageFactory - Creating SAAJ 1.3 MessageFactory with SOAP 1.1 Protocol
22:07:22.068 [main] INFO org.springframework.oxm.jaxb.Jaxb2Marshaller - Creating JAXBContext with context path [com.datapower.schemas.management]
22:07:24.446 [main] INFO org.springframework.oxm.jaxb.Jaxb2Marshaller - Creating JAXBContext with context path [com.datapower.schemas.management]
22:07:26.554 [main] INFO org.springframework.ws.soap.saaj.SaajSoapMessageFactory - Creating SAAJ 1.3 MessageFactory with SOAP 1.1 Protocol
I have an app using embedded Jetty. Everything works well, except for logging. I am now trying to use logback, but am getting fatal errors.
The app loads as you can see:
$ java -XX:+UseConcMarkSweepGC -XX:PermSize=64M -XX:MaxPermSize=256M -Xms1G -Xmx1G -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar /usr/local/mexp/mexp.jar server /usr/local/mexp/mexp.json
10:46:02.093 [main] DEBUG org.eclipse.jetty.util.log - Logging to Logger[org.eclipse.jetty.util.log] via org.eclipse.jetty.util.log.Slf4jLog
10:46:02.098 [main] INFO org.eclipse.jetty.util.log - Logging initialized #76ms
followed by pages and pages of DEBUG statements describing loading of every class in my app. This suggests it is not finding the logback.xml, where I have set logging level for org.eclipse.jetty to ERROR.
Eventually, I am getting the following exceptions when the app loads:
10:46:30.349 [main] DEBUG o.e.jetty.webapp.WebAppClassLoader - loaded class org.slf4j.impl.StaticLoggerBinder from sun.misc.Launcher$AppClassLoader#659c2931
10:46:30.354 [main] WARN o.e.j.u.component.AbstractLifeCycle - FAILED o.e.j.w.WebAppContext#4e4e745{/,file:/usr/local/mexp/resources/webapp/,STARTING}{file:/usr/local/mexp/mexp.jar}: java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type LoggerFactory; used in the signature
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type LoggerFactory; used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:306) ~[mexp.jar:na]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276) ~[mexp.jar:na]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) ~[mexp.jar:na]
at com.rc.util.logging.RCLog.<init>(RCLog.java:28) ~[mexp.jar:na]
at com.rc.commonwebapp.servlet.filter.SessionTXManager.<init>(SessionTXManager.java:43) ~[na:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.7.0_45]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) ~[na:1.7.0_45]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_45]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_45]
at java.lang.Class.newInstance(Class.java:374) ~[na:1.7.0_45]
at org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2370) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1146) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:120) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:850) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1341) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1334) ~[mexp.jar:na]
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:497) ~[mexp.jar:na]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [mexp.jar:na]
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) [mexp.jar:na]
at org.eclipse.jetty.server.Server.start(Server.java:380) [mexp.jar:na]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) [mexp.jar:na]
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) [mexp.jar:na]
at org.eclipse.jetty.server.Server.doStart(Server.java:347) [mexp.jar:na]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) [mexp.jar:na]
at com.pronto.JettyWebApp.main(JettyWebApp.java:95) [mexp.jar:na]
and
java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type LoggerFactory; used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:306) ~[mexp.jar:na]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276) ~[mexp.jar:na]
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288) ~[mexp.jar:na]
at com.rc.util.logging.RCLog.<init>(RCLog.java:28) ~[mexp.jar:na]
at com.rc.commonwebapp.servlet.filter.SessionTXManager.<init>(SessionTXManager.java:43) ~[na:na]
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) ~[na:1.7.0_45]
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57) ~[na:1.7.0_45]
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) ~[na:1.7.0_45]
at java.lang.reflect.Constructor.newInstance(Constructor.java:526) ~[na:1.7.0_45]
at java.lang.Class.newInstance(Class.java:374) ~[na:1.7.0_45]
at org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2370) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1146) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:120) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:850) ~[mexp.jar:na]
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1341) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1334) ~[mexp.jar:na]
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741) ~[mexp.jar:na]
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:497) ~[mexp.jar:na]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) ~[mexp.jar:na]
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132) ~[mexp.jar:na]
at org.eclipse.jetty.server.Server.start(Server.java:380) ~[mexp.jar:na]
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114) ~[mexp.jar:na]
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61) ~[mexp.jar:na]
at org.eclipse.jetty.server.Server.doStart(Server.java:347) ~[mexp.jar:na]
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68) ~[mexp.jar:na]
at com.pronto.JettyWebApp.main(JettyWebApp.java:95) [mexp.jar:na]
Exception in thread "main" java.lang.LinkageError: loader constraint violation: when resolving method "org.slf4j.impl.StaticLoggerBinder.getLoggerFactory()Lorg/slf4j/ILoggerFactory;" the class loader (instance of org/eclipse/jetty/webapp/WebAppClassLoader) of the current class, org/slf4j/LoggerFactory, and the class loader (instance of sun/misc/Launcher$AppClassLoader) for resolved class, org/slf4j/impl/StaticLoggerBinder, have different Class objects for the type LoggerFactory; used in the signature
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:306)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:288)
at com.rc.util.logging.RCLog.<init>(RCLog.java:28)
at com.rc.commonwebapp.servlet.filter.SessionTXManager.<init>(SessionTXManager.java:43)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:526)
at java.lang.Class.newInstance(Class.java:374)
at org.eclipse.jetty.server.handler.ContextHandler$Context.createInstance(ContextHandler.java:2370)
at org.eclipse.jetty.servlet.ServletContextHandler$Context.createFilter(ServletContextHandler.java:1146)
at org.eclipse.jetty.servlet.FilterHolder.initialize(FilterHolder.java:120)
at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:850)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:298)
at org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1341)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1334)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:741)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:497)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
at org.eclipse.jetty.server.Server.start(Server.java:380)
at org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
at org.eclipse.jetty.server.Server.doStart(Server.java:347)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at com.pronto.JettyWebApp.main(JettyWebApp.java:95)
Some web searching on java.lang.LinkageError suggests that Jetty and my app have different class loaders that are conflicting when trying to load LoggerFactory. I'm not sure what to do next.
ETA:
Per #PavelHoral's suggestion I added <scope>provided</scope> to my pom.xml (dependencyManagement section) but that results in this when I attempt to start the app:
2014-09-28 16:47:42.491:INFO::main: Logging initialized #66ms
Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at com.rc.util.config.ConfigurationManager.<clinit>(ConfigurationManager.java:31)
at com.pronto.JettyWebApp.main(JettyWebApp.java:39)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
... 2 more
ETA: Per suggestion by #hd1 I added the bridge, which got rid of the LinkageError, so we're part way there. I'm still stymied by the fact that all of the logging goes to stdout and it's still at level DEBUG - not acceptable for a prod environment for sure, so I need to be able to configure this. Here is my logback.xml:
<configuration>
<appender name="FILE" class="ch.qos.logback.core.FileAppender">
<file>/usr/local/mexp/logs/mexp.service.log</file>
<encoder>
<pattern>"%-5p [%d{dd-MMM-yy HH:mm:ss}] [%t] %-20c %-3x:%m%n</pattern>
</encoder>
</appender>
<appender name="AXIS" class="ch.qos.logback.core.FileAppender">
<file>/usr/local/mexp/logs/axis.log</file>
<encoder>
<pattern>%-5p [%d{dd-MMM-yy HH:mm:ss}] :%m%n</pattern>
</encoder>
</appender>
<appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender">
<!-- The default pattern: Date Priority [Category] Message\n -->
<encoder>
<pattern>%d{ABSOLUTE} %-5p [%c{1}] %m%n</pattern>
</encoder>
</appender>
<appender name="ASYNC" class="ch.qos.logback.classic.AsyncAppender">
<appender-ref ref="AXIS"/>
</appender>
<logger name="org.apache">
<level value="ERROR"/>
</logger>
<logger name="org.quartz">
<level value="ERROR" />
</logger>
<logger name="org.hibernate">
<level value="ERROR" />
</logger>
<logger name="org.apache.struts.action">
<level value="INFO"/>
</logger>
<logger name="org.apache.catalina.cluster">
<level value="INFO"/>
</logger>
<logger name="org">
<level value="ERROR" />
</logger>
<logger name="net">
<level value="ERROR" />
</logger>
<logger name="org.apache.axis.transport.http.HTTPSender" additivity="false">
<level value="ERROR"/>
<appender-ref ref="ASYNC"/>
</logger>
<logger name="com.mchange">
<level value="ERROR"/>
</logger>
<!-- this silences the HttpClient chatter that starts with "httpclient.wire.header" and "httpclient.wire.content" -->
<logger name="org.apache.commons.httpclient">
<level value="fatal"/>
</logger>
<logger name="httpclient.wire.header">
<level value="fatal"/>
</logger>
<logger name="httpclient.wire.content">
<level value="fatal"/>
</logger>
<logger name="org.eclipse.jetty">
<level value="ERROR"/>
</logger>
<!-- Log the real SQL -->
<logger name="org.hibernate.SQL">
<level value="ERROR"/>
</logger>
<root level="ERROR">
<appender-ref ref="FILE"/>
</root>
</configuration>
ETA: I also tried the logging separation described here - added this to web.xml:
<env-entry>
<env-entry-name>logback/context-name</env-entry-name>
<env-entry-type>java.lang.String</env-entry-type>
<env-entry-value>mexp</env-entry-value>
</env-entry>
and this in my jetty runner main method
System.setProperty("logback.ContextSelector", "JNDI");
(and changed the name of the logback file to logback-mexp.xml) but all of that results in no change in behavior.
We're definitely getting closer, but for the bounty I need the whole solution. Thanks!
ETA the current state of things. I no longer get the LinkageError. My app loads and performs fine. In fact there has been a considerable improvement in that now I don't get pages and pages of DEBUG lines in stdout. I still get all my logging in stdout, like so:
$ java -XX:+UseConcMarkSweepGC -XX:PermSize=64M -XX:MaxPermSize=256M -Xms1G -Xmx1G -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/tmp -jar /usr/local/mexp/mexp.jar server /usr/local/mexp/mexp.json
Oct 01, 2014 3:54:28 PM org.springframework.web.context.ContextLoader initWebApplicationContext
INFO: Root WebApplicationContext: initialization started
Oct 01, 2014 3:54:28 PM org.springframework.web.context.support.XmlWebApplicationContext prepareRefresh
INFO: Refreshing Root WebApplicationContext: startup date [Wed Oct 01 15:54:28 EDT 2014]; root of context hierarchy
Oct 01, 2014 3:54:28 PM org.springframework.beans.factory.xml.XmlBeanDefinitionReader loadBeanDefinitions
INFO: Loading XML bean definitions from class path resource [mexpPapiContext.xml]
Oct 01, 2014 3:54:28 PM org.springframework.web.context.ContextLoader initWebApplicationContext
INFO: Root WebApplicationContext: initialization completed in 352 ms
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/usr/local/mexp/resources/webapp/WEB-INF/lib/slf4j-log4j12-1.7.7.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/usr/local/mexp/mexp.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
15:54:28,596 INFO GlobalRootManager:85 - Entering initialization
15:54:28,840 INFO GlobalRootManager:85 - Exiting initialization
15:54:28,868 INFO FileUtil:220 - -> Found /mpds.properties in resource bundle
Oct 01, 2014 3:54:29 PM org.apache.struts.action.ActionServlet initChain
INFO: Loading chain catalog from jar:file:/usr/local/mexp/resources/webapp/WEB-INF/lib/struts-core-1.3.10.jar!/org/apache/struts/chain/chain-config.xml
Oct 01, 2014 3:54:29 PM org.apache.struts.action.ActionServlet initChain
INFO: Loading chain catalog from jar:file:/usr/local/mexp/mexp.jar!/org/apache/struts/chain/chain-config.xml
Oct 01, 2014 3:54:29 PM org.apache.struts.validator.ValidatorPlugIn initResources
INFO: Loading validation rules file from '/WEB-INF/struts/validator-rules.xml'
Oct 01, 2014 3:54:29 PM org.apache.struts.validator.ValidatorPlugIn initResources
INFO: Loading validation rules file from '/WEB-INF/struts/validation-mexp.xml'
15:54:29,529 INFO QuartzStartupServlet:85 - Entering servlet init.
15:54:29,562 INFO StdSchedulerFactory:1184 - Using default implementation for ThreadExecutor
15:54:29,575 INFO SchedulerSignalerImpl:61 - Initialized Scheduler Signaller of type: class org.quartz.core.SchedulerSignalerImpl
15:54:29,575 INFO QuartzScheduler:240 - Quartz Scheduler v.2.2.1 created.
15:54:29,576 INFO XMLSchedulingDataProcessorPlugin:200 - Registering Quartz Job Initialization Plug-in.
15:54:29,578 INFO RAMJobStore:155 - RAMJobStore initialized.
15:54:29,578 INFO QuartzScheduler:305 - Scheduler meta-data: Quartz Scheduler (v2.2.1) 'MexpScheduler' with instanceId 'dev'
Scheduler class: 'org.quartz.core.QuartzScheduler' - running locally.
NOT STARTED.
Currently in standby mode.
Number of jobs executed: 0
Using thread pool 'org.quartz.simpl.SimpleThreadPool' - with 5 threads.
Using job-store 'org.quartz.simpl.RAMJobStore' - which does not support persistence. and is not clustered.
15:54:29,578 INFO StdSchedulerFactory:1339 - Quartz scheduler 'MexpScheduler' initialized from an externally provided properties instance.
15:54:29,578 INFO StdSchedulerFactory:1343 - Quartz scheduler version: 2.2.1
15:54:29,592 INFO XMLSchedulingDataProcessor:471 - Parsing XML file: mexp-dev-jobs.xml with systemId: mexp-dev-jobs.xml
15:54:29,948 INFO XMLSchedulingDataProcessor:996 - Adding 13 jobs, 13 triggers.
15:54:29,949 INFO XMLSchedulingDataProcessor:1034 - Adding job: skuLevelBiddingReportGroup.skuLevelBiddingReportJob
15:54:29,951 INFO XMLSchedulingDataProcessor:1034 - Adding job: emailNotificationsGroup.emailNotificationsJob
15:54:29,952 INFO XMLSchedulingDataProcessor:1034 - Adding job: balanceReplenishmentGroup.balanceReplenishmentJob
15:54:29,953 INFO XMLSchedulingDataProcessor:1034 - Adding job: balanceReplenishmentCappedInvoiceGroup.balanceReplenishmentCappedInvoiceJob
15:54:29,954 INFO XMLSchedulingDataProcessor:1034 - Adding job: merchantTxnProcessingGroup.merchantTxnProcessingJob
15:54:29,956 INFO XMLSchedulingDataProcessor:1034 - Adding job: feedFileManagerGroup.feedFileManagerJob
15:54:29,957 INFO XMLSchedulingDataProcessor:1034 - Adding job: merchantPaymentManagerGroup.merchantPaymentManagerJob
15:54:29,958 INFO XMLSchedulingDataProcessor:1032 - Replacing job: merchantTxnProcessingGroup.merchantTxnProcessingJob
15:54:29,958 INFO XMLSchedulingDataProcessor:1034 - Adding job: expiredAccountUpdaterGroup.expiredAccountUpdaterJob
15:54:29,959 INFO XMLSchedulingDataProcessor:1034 - Adding job: placementsForDatasyncUpdaterGroup.placementsForDatasyncUpdaterJob
15:54:29,960 INFO XMLSchedulingDataProcessor:1034 - Adding job: placementPaymentProcessingGroup.placementPaymentProcessingJob
15:54:29,961 INFO XMLSchedulingDataProcessor:1034 - Adding job: switchingMerchantsToInvoiceGroup.switchingMerchantsToInvoiceJob
15:54:29,962 INFO XMLSchedulingDataProcessor:1034 - Adding job: toggleActiveStateGroup.toggleActiveStateJob
15:54:29,963 INFO QuartzScheduler:575 - Scheduler MexpScheduler_$_dev started.
15:54:29,982 INFO LoggingTriggerHistoryPlugin:387 - Trigger JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml fired job JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml at: 15:54:29 10/01/2014
15:54:29,983 INFO LoggingJobHistoryPlugin:469 - Job JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml fired (by trigger JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml) at: 15:54:29 10/01/2014
15:54:29,984 INFO LoggingJobHistoryPlugin:513 - Job JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml execution complete at 15:54:29 10/01/2014 and reports: null
15:54:29,984 INFO LoggingTriggerHistoryPlugin:433 - Trigger JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml completed firing job JobSchedulingDataLoaderPlugin.JobSchedulingDataLoaderPlugin_jobInitializer_mexp-dev-jobs_xml at 15:54:29 10/01/2014 with resulting trigger instruction code: DO NOTHING
Please see this page on the slf4j site. I suspect you've not included the appropriate bridge jar. For example, for log4j, you're going to need the following stanzas in your pom.xml:
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.17</version>
</dependency>
Hope that helps. If not, feel free to leave a comment.
I do not think there is a silver bullet here: logging in Java takes many forms and it takes attention to detail to get it right. Especially when class-loaders come in to play as is the case with web-apps.
The explanation about how logging works with Slf4j by Joakim Erdfelt is pretty good (I saw this in the mail-conversation you had with him earlier).
I can only add to do a proper clean-up:
put the jar-files for Logback, the Slf4j-api and the required Slf4j-bridges (jcl-over-slf4j, log4j-over-slf4j) in the main/common/launch class-path.
remove everything else that has anything to do with logging (log4j, commons-logging, etc.). The "dependencyManagement with scope provided" trick mentioned in the comments by Pavel Horal can come in handy here.
for some components you need to programmatically set Slf4j as logger, e.g. for Hibernate 4.3 use System.setProperty("org.jboss.logging.provider", "slf4j"); before Hibernate is started.
if Slf4j cannot be set as logger for a component, try setting Log4j. The slf4j-bridge "log4j-over-slf4j" will redirect the logging from Log4j to Slf4j and Slf4j will send it to the logging implementation (Logback). Note that you only need the bridge jar-file "log4j-over-slf4j" and NOT the log4j-jar (the bridge will provide replacements for the Log4j classes) in your main class-path.
You should now have only one jar-file and/or class in your entire assembly for your application for each logging related component mentioned in the first point of the clean-up. Double check that there are no logging related jar-files in any of the web-apps (WEB-INF/lib folders). On a side node: if you use JDBC-drivers, follow the same procedure (these tend to give trouble as well if they are not in the main class-path).
Before you start the clean-up you should verify your basic setup by using Logback with the Jetty embedded Hello World example.
It takes some effort to get all this logging going but, as you said, it is required for production and it has helped me during development: simply switching on trace/debugging for a third-party component (via a logger-category in logback-test.xml) can provide a lot of insight in what is happening (especially when combined with unit-tests).
I had this proble. Turns out I found an embarrasingly easy sollution (in my case).
Jetty didn't find my slf4j-*.jar(s) unless I added them as dependencies to the plugin configuration itself. I will not include my entire pom.xml but merely the plugin conf. Hope this helps.
Cheers
...
<plugin>
<groupId>org.mortbay.jetty</groupId>
<artifactId>jetty-maven-plugin</artifactId>
<version>8.1.10.v20130312</version>
<configuration>
<webAppConfig>
</webAppConfig>
</configuration>
<dependencies>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-log4j12</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>log4j-over-slf4j</artifactId>
<version>1.7.7</version>
</dependency>
<dependency>
<groupId>org.codehaus.fabric3</groupId>
<artifactId>fabric3-atomikos-library</artifactId>
<version>1.9.6</version>
</dependency>
<dependency>
<groupId>javax.transaction</groupId>
<artifactId>jta</artifactId>
<version>1.1</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>org.codehaus.btm</groupId>
<artifactId>btm-jetty6-lifecycle</artifactId>
<version>1.3.3</version>
</dependency>
</dependencies>
</plugin>
...
I then checked the project dependency tree using the Maven Dependency Plugin and removed/excluded all unwanted logging frameworks included by dependencies and it worked.