I have a multithreaded application and im using log4j for the logging. When i test my application on my windows 7/intel laptop, it works just fine. But when i deploy the same application to the production server(solaris/sparc), it works for 10 minutes then starts to slow down(very slow). I used profiler to see the threads state. There were a lot of threads blocked because of the log4j operations in the thread dump. Im also using async appender but coulnd't manage to get any successful result. Any guess?
Here are some dump:
"pool-7-thread-105" - Thread t#22939
java.lang.Thread.State: BLOCKED
at org.apache.log4j.Category.callAppenders(Category.java:204)
- waiting to lock <794f2dae> (a org.apache.log4j.spi.RootLogger) owned by "pool-7-thread-112" t#22946
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.info(Category.java:666)
"pool-7-thread-112" - Thread t#22946
java.lang.Thread.State: RUNNABLE
at java.io.FileOutputStream.writeBytes(Native Method)
at java.io.FileOutputStream.write(Unknown Source)
at java.io.BufferedOutputStream.flushBuffer(Unknown Source)
at java.io.BufferedOutputStream.flush(Unknown Source)
- locked <5fcbc329> (a java.io.BufferedOutputStream)
at java.io.PrintStream.write(Unknown Source)
- locked <19e9d0c5> (a java.io.PrintStream)
at sun.nio.cs.StreamEncoder.writeBytes(Unknown Source)
at sun.nio.cs.StreamEncoder.implFlushBuffer(Unknown Source)
at sun.nio.cs.StreamEncoder.implFlush(Unknown Source)
at sun.nio.cs.StreamEncoder.flush(Unknown Source)
- locked <3680c465> (a java.io.OutputStreamWriter)
at java.io.OutputStreamWriter.flush(Unknown Source)
at org.apache.log4j.helpers.QuietWriter.flush(QuietWriter.java:59)
at org.apache.log4j.WriterAppender.subAppend(WriterAppender.java:324)
at org.apache.log4j.WriterAppender.append(WriterAppender.java:162)
at org.apache.log4j.AppenderSkeleton.doAppend(AppenderSkeleton.java:251)
- locked <3fddded7> (a org.apache.log4j.ConsoleAppender)
at org.apache.log4j.helpers.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:66)
at org.apache.log4j.Category.callAppenders(Category.java:206)
- locked <794f2dae> (a org.apache.log4j.spi.RootLogger)
at org.apache.log4j.Category.forcedLog(Category.java:391)
at org.apache.log4j.Category.info(Category.java:666)
Also log4j.xml - version 1.2.17
<appender name="scripts" class="org.apache.log4j.DailyRollingFileAppender">
<param name="threshold" value="INFO"/>
<param name="file" value="log/script.log"/>
<param name="DatePattern" value="'.'yyyy-MM-dd"/>
<layout class="org.apache.log4j.EnhancedPatternLayout">
<param name="ConversionPattern"
value="%-6p[%-d{ISO8601}] [%t] %m (%F:%L) %n"/>
</layout>
</appender>
<appender name="stdout" class="org.apache.log4j.ConsoleAppender">
<param name="threshold" value="INFO"/>
<layout class="org.apache.log4j.PatternLayout">
<param name="ConversionPattern" value="%-6p[%-d{ISO8601}] [%t] %m (%F:%L) %n"/>
</layout>
</appender>
<appender name="ASYNC" class="org.apache.log4j.AsyncAppender">
<param name="BufferSize" value="5000"/>
<appender-ref ref="scripts"/>
</appender>
<root>
<priority value="debug"/>
<appender-ref ref="stdout"/>
<appender-ref ref="ASYNC"/>
</root>
So the threads that are trying to log are blocked. Why? Because a logging thread is currently blocked in java.io.FileOutputStream.writeBytes(Native Method). That strongly suggests that the thing the logging is going to (a file or whatever) cannot keep up with the amount of logging being done.
The way to troubleshoot this is to start with looking at where your logging is going. If it's going to a file, is that file on a fast, local filesystem? Is disk I/O an issue?
You may wish to use a logging scheme that doesn't block on I/O. It doesn't have to -- other threads can log to an internal queue while a thread is doing disk I/O. However, if the logging rate exceeds the I/O rate, eventually you have to stop logging from building up in memory somehow, and that requires either blocking threads or throwing log entries away. That said, this shouldn't be an issue unless you are either logging way too much, have a serious I/O performance issue (like logging over NFS on a crowded network), or have file buffering disabled somehow.
Judging from the stack dump, something is calling flush() ... so that is going to negate a lot of the "goodness" of using BufferedOutputStream. If you can figure out how to avoid the flushes the throughput will improve.
David Schwartz comments thus:
Windows is notorious for not really honoring file flushes as a way to improve its performance. Solaris and Linux really do full flushes. This might help explain the platform-dependent performance difference.
(I didn't know that. And yes it would.)
Turning off immediateFlush in the WriterAppender might help
Excellent advice.
Related
I have a Java maven application in which I have created a swing GUI.
I am using logback-classic for logging purposes. logback.xml is present under the src/main/resources directory.
When I run the application using eclipse "Run As Java Application", it is working as intended and application is logging to the console and log file.
But after exporting the application as a runnable JAR file and double clicking to run the application, it is not logging to file.
When I opened command prompt and execute application using "java -jar myjarfile.jar", I am able to see the console logs, but it is using the default logback configuration.
I tried giving additional parameter, -Dlogback.configurationFile="path-to-file/logback.xml" and I am getting the below error,
Failed to instantiate [ch.qos.logback.classic.LoggerContext] Reported
exception: java.lang.IllegalArgumentException: name
at sun.misc.URLClassPath$Loader.findResource(Unknown Source)
at sun.misc.URLClassPath$1.next(Unknown Source)
at sun.misc.URLClassPath$1.hasMoreElements(Unknown Source)
at java.net.URLClassLoader$3$1.run(Unknown Source)
at java.net.URLClassLoader$3$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader$3.next(Unknown Source)
at java.net.URLClassLoader$3.hasMoreElements(Unknown Source)
at sun.misc.CompoundEnumeration.next(Unknown Source)
at sun.misc.CompoundEnumeration.hasMoreElements(Unknown Source)
at ch.qos.logback.core.util.Loader.getResources(Loader.java:73)
at ch.qos.logback.classic.util.ContextInitializer.multiplicityWarning(ContextInitializer.java:183)
at ch.qos.logback.classic.util.ContextInitializer.statusOnResourceSearch(ContextInitializer.java:175)
at ch.qos.logback.classic.util.ContextInitializer.findConfigFileURLFromSystemProperties(ContextInitializer.java:111)
at ch.qos.logback.classic.util.ContextInitializer.findURLOfDefaultConfigurationFile(ContextInitializer.java:120)
at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:148)
at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
at org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at com.esignature.tools.templatemigration.ConverterGUI.(ConverterGUI.java:35)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Unknown Source)
at org.eclipse.jdt.internal.jarinjarloader.JarRsrcLoader.main(JarRsrcLoader.java:59)
I don't know what I am missing and I want to log from runnable JAR to the log file.
It is confusing because it is working from eclipse but not from the exported runnable JAR.
Below is the logback.xml file.
<?xml version="1.0" encoding="UTF-8"?>
<configuration>
<property name="LOG_HOME" value="C:/template converter logs" />
<appender name="STDOUT"
class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level - %msg%n</pattern>
</encoder>
</appender>
<appender name="rollingFile"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<rollingPolicy
class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
<fileNamePattern>${LOG_HOME}/applog-%d{yyyy-MM-dd}.log</fileNamePattern>
</rollingPolicy>
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level - %msg%n</pattern>
</encoder>
</appender>
<root level="debug">
<appender-ref ref="STDOUT" />
<appender-ref ref="rollingFile" />
</root>
</configuration>
The error you are facing is because there is two logback.xml configuration, one is in your classpath and you are trying to override/add another one using -Dlogback.configurationFile
In my case when packaging the runnable JAR I changed the pom configuration to this.
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<executable>true</executable>
</configuration>
</plugin>
Note the executable set to true, this makes sure that a MANIFEST.MF file is added to the JAR package.
So in order to make this work with this config I added this property to my application.yml/application.properties
logging:
config: file:D:\\LogConfig\\logback.xml
Then I proceed to generate the JAR file using clean, install mvn commands.
From there running the JAR file using java -jar myJar.jar works fine and there is no need to add arguments to search the application.yml or logback.xml. That is because the properties is being loaded from within the jar and the log config from the specified route on the application.yml .
Using maven shade plugin to generate a shaded JAR file that includes the dependencies and the custom logback.xml is one working solution that I utilized.
Now when I run this JAR file (either from command line or by double-clicking it), logs are generated in the specified location as expected.
We have a SmtpAppender configured with a custom RateLimiter filter and ERROR log level, everything is working as expected except for the exceptions format, they are including the source code location which we would like to remove, we add such appender programmatically to each logger after the logging facility has been initialized, example of log:
2019-05-03 10:39:58,871 Thread-9 ERROR s.utils.Startup - Testing error
java.lang.RuntimeException: Testing error
at com.somepackage.SomeClass.lambda$enableEmailLogging$0(Startup.java:619) ~[classes/:?]
at java.lang.Thread.run(Thread.java:748) [?:1.8.0_212]
The ~[classes/:?] and [?:1.8.0_212] are annoying to us, also; in general we would like our logging to always include the exceptions which is well accomplished in our RollingRandomAccessFile appender as well, but having the same problem of stack trace source code location being included, here is also a snippet of our rolling file appender:
<Appenders>
<RollingRandomAccessFile name="RollingFile" fileName="/opt/tomcat/logs/some-webapp.log"
filePattern="/opt/tomcat/logs/some-webapp.log-%d{yyMMdd-HH}"
ignoreExceptions="false">
<PatternLayout>
<Pattern>%d{DEFAULT} %15.15t %-5p %15.15c - %m%n</Pattern>
</PatternLayout>
<Policies>
<TimeBasedTriggeringPolicy/>
</Policies>
</RollingRandomAccessFile>
</Appenders>
I have looked all over for a way to accomplish this with no luck.
Changing the PatternLayout's pattern from:
%d{DEFAULT} %15.15t %-5p %15.15c - %m%n
to
%d{DEFAULT} %15.15t %-5p %15.15c - %m%n%throwable
and removing the option ignoreExceptions from the appenders seem to accomplish what I wanted.
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've got a Spring Boot command line application using Spring Integration. The application is running within a service wrapper.
At start up, everything seems to run smoothly with no exceptions. However, if I drop a file in the observed directory nothing triggers the inbound-channel-adapter.
Is it at all possible the service wrapper is causing the polling to not run?
UPDATE
I added a logback.xml configuration
<configuration>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<logger name="org.springframework.integration" level="DEBUG">
<appender-ref ref="STDOUT" />
</logger>
</configuration>
But now the log is not receiving any input with this config. STDOUT works fine without the config. Makes is difficult to enable DEBUG for the integration package.
I based my wrapper on this project
UPDATE #2
I finally got logging working. I had a mistake in assuming it was not a ERROR level issue.
13:29:52.925 [task-scheduler-10] ERROR o.s.i.handler.LoggingHandler - org.springframework.messaging.MessagingException: The path [\\server\sharepath] does not denote a properly accessible directory.
at org.springframework.integration.file.DefaultDirectoryScanner.listFiles(DefaultDirectoryScanner.java:83)
at org.springframework.integration.file.FileReadingMessageSource.scanInputDirectory(FileReadingMessageSource.java:293)
at org.springframework.integration.file.FileReadingMessageSource.receive(FileReadingMessageSource.java:272)
at org.springframework.integration.endpoint.SourcePollingChannelAdapter.receiveMessage(SourcePollingChannelAdapter.java:175)
at org.springframework.integration.endpoint.AbstractPollingEndpoint.doPoll(AbstractPollingEndpoint.java:224)
at org.springframework.integration.endpoint.AbstractPollingEndpoint.access$000(AbstractPollingEndpoint.java:57)
at org.springframework.integration.endpoint.AbstractPollingEndpoint$1.call(AbstractPollingEndpoint.java:176)
at org.springframework.integration.endpoint.AbstractPollingEndpoint$1.call(AbstractPollingEndpoint.java:173)
at org.springframework.integration.endpoint.AbstractPollingEndpoint$Poller$1.run(AbstractPollingEndpoint.java:330)
at org.springframework.integration.util.ErrorHandlingTaskExecutor$1.run(ErrorHandlingTaskExecutor.java:55)
at org.springframework.core.task.SyncTaskExecutor.execute(SyncTaskExecutor.java:50)
at org.springframework.integration.util.ErrorHandlingTaskExecutor.execute(ErrorHandlingTaskExecutor.java:51)
at org.springframework.integration.endpoint.AbstractPollingEndpoint$Poller.run(AbstractPollingEndpoint.java:324)
at org.springframework.scheduling.support.DelegatingErrorHandlingRunnable.run(DelegatingErrorHandlingRunnable.java:54)
at org.springframework.scheduling.concurrent.ReschedulingRunnable.run(ReschedulingRunnable.java:81)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(Unknown Source)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
The issue is that the network path cannot be determined if accessible by Java/Spring.
13:29:52.925 [task-scheduler-10] ERROR o.s.i.handler.LoggingHandler -
org.springframework.messaging.MessagingException: The path
[\server\sharepath] does not denote a properly accessible directory.
I'm having problems with my logging where slf4j doesn't log the filename and row number of the message/stacktrace.
Code:
private static Logger log = LoggerFactory.getLogger(SomeService.class);
#Override
public void aService(ServiceAdmin sa) throws Exception {
log.debug(LoggerFactory.class.toString());
log.debug(log.getClass().getName());
log.debug("Setup Example");
SomeService.setDefault(Example.getInstance());
log.debug("Example finished");
}
Log:
2015-04-20 14:47:26.573 DEBUG [main] null:-1 - class org.slf4j.LoggerFactory
2015-04-20 14:47:26.574 DEBUG [main] null:-1 - ch.qos.logback.classic.Logger
2015-04-20 14:47:26.574 DEBUG [main] null:-1 - Setup Example
2015-04-20 14:47:26.575 DEBUG [main] null:-1 - SomeService finished
This is pars of my logback.xml that relates to this class
<logger name="com.bredband.nexusgw.services">
<level value="debug" />
<appender-ref ref="nexusservice" />
</logger>
<appender name="nexusservice"
class="ch.qos.logback.core.rolling.RollingFileAppender">
<File>/var/log/nexus/nexusjgw/jgw/Service.log</File>
<rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy">
<FileNamePattern>/var/log/nexus/nexusjgw/jgw/Service.log.%i
</FileNamePattern>
<MinIndex>1</MinIndex>
<MaxIndex>5</MaxIndex>
</rollingPolicy>
<triggeringPolicy
class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy">
<MaxFileSize>200MB</MaxFileSize>
</triggeringPolicy>
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>debug</level>
</filter>
<layout class="ch.qos.logback.classic.PatternLayout">
<Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %5p [%t] %F:%L - %m%n</Pattern>
</layout>
</appender>
Has anyone seen this before and can point me in the right direction?
BR
Stefan
-- Update --
I changed the %F to %C, but that didn't change anything in the logs. Then I tried to set debug = "on" in the javac header in my ant file and now it's logging classname and line number.
2015-04-21 08:28:55.910 DEBUG [main] Service.java:20 - class org.slf4j.LoggerFactory
2015-04-21 08:28:55.911 DEBUG [main] Service.java:21 - ch.qos.logback.classic.Logger
2015-04-21 08:28:55.911 DEBUG [main] Service.java:22 - Setup Example
2015-04-21 08:28:55.912 DEBUG [main] Service.java:24 - Example finished
Although this is working, it's not something I've changed before. The only thing that has changed in this project over time is the addition of other external jars. I'm not really sure how adding a duplicate/newer/older version of slf4j in another external jar would affect the logging though, any version should look for the logback file?
-- Update --
After checking alot of historical checkins of the build.xml file I found that we actually had debug = "on" earlier and the problem may actually have been introduced by this parameter beeing set to "off".
Thank you for your help.
BR
Stefan
You should first make sure that you compile your application with debug information. If calling javac directly, then it is the -g command-line parameter. However most build tools (like maven or ant) have a specific way to provide this parameter.
You may also want to replace %F with %C, which should work without the debug information.