- logback-user - mailman3.qos.ch

Fwd: logback start listener invoked twice
by Евгений Бушуев 19 Jul '16

19 Jul '16

Hello Could somebody please explain if it's ok when statusListener.start method is invoked twice? I.e. can it be bug rather than feature? As far as I understand it's getting invoked from LogerFactory.bind method: private final static void bind() { ... Set<URL> staticLoggerBinderPathSet = null; // skip check under android, see also http://jira.qos.ch/browse/SLF4J-328 if (!isAndroid()) { staticLoggerBinderPathSet = findPossibleStaticLoggerBinderPathSet(); reportMultipleBindingAmbiguity(staticLoggerBinderPathSet); } // the next line does the binding StaticLoggerBinder.getSingleton(); <---fist from here INITIALIZATION_STATE = SUCCESSFUL_INITIALIZATION; reportActualBinding(staticLoggerBinderPathSet); replayEvents(); <---then from here ... } The stacktraces: Connected to the target VM, address: 'localhost:7778', transport: 'socket' at my.app.LogListener.start(PECQuartzListener.java:41) at ch.qos.logback.core.joran.action.StatusListenerAction.end(StatusListenerAction.java:65) at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:155) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:142) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:103) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84) at org.slf4j.impl.StaticLoggerBinder.<clinit>(StaticLoggerBinder.java:55) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:149) <================================= at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:390) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:340) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:361) at my.app.AuthorisationListener.<init>(AuthorisationListener.java:34) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at com.ibm.ws.managedobject.internal.ManagedObjectFactoryImpl.createManagedObject(ManagedObjectFactoryImpl.java:65) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.inject(WebApp.java:1250) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1416) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1404) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.loadListener(WebApp.java:813) at com.ibm.ws.webcontainer.webapp.WebApp.loadLifecycleListeners(WebApp.java:2246) at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:1040) at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:6463) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp(DynamicVirtualHost.java:446) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApplication(DynamicVirtualHost.java:441) at com.ibm.ws.webcontainer.osgi.WebContainer.startWebApplication(WebContainer.java:1000) at com.ibm.ws.webcontainer.osgi.WebContainer.startModule(WebContainer.java:824) at com.ibm.ws.app.manager.web.internal.WebModuleHandlerImpl.deployModule(WebModuleHandlerImpl.java:103) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployModule(DeployedAppInfoBase.java:871) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployModules(DeployedAppInfoBase.java:831) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:818) at com.ibm.ws.app.manager.ear.internal.EARApplicationHandlerImpl.install(EARApplicationHandlerImpl.java:84) at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1192) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) java.lang.Exception at my.app.LogListener.start(PECQuartzListener.java:41) at ch.qos.logback.core.joran.action.StatusListenerAction.end(StatusListenerAction.java:65) at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:309) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:193) at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:179) at ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:62) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:155) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:142) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:103) at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53) at ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75) at ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150) at ch.qos.logback.classic.selector.ContextJNDISelector.getLoggerContext(ContextJNDISelector.java:108) at org.slf4j.impl.StaticLoggerBinder.getLoggerFactory(StaticLoggerBinder.java:108) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:396) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:340) at org.slf4j.LoggerFactory.replaySingleEvent(LoggerFactory.java:220) at org.slf4j.LoggerFactory.replayEvents(LoggerFactory.java:195) at org.slf4j.LoggerFactory.bind(LoggerFactory.java:152) <================================= at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124) at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:390) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:340) at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:361) at my.app.AuthorisationListener.<init>(AuthorisationListener.java:34) at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) at java.lang.reflect.Constructor.newInstance(Constructor.java:422) at com.ibm.ws.managedobject.internal.ManagedObjectFactoryImpl.createManagedObject(ManagedObjectFactoryImpl.java:65) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.inject(WebApp.java:1250) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1416) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.injectAndPostConstruct(WebApp.java:1404) at com.ibm.ws.webcontainer.osgi.webapp.WebApp.loadListener(WebApp.java:813) at com.ibm.ws.webcontainer.webapp.WebApp.loadLifecycleListeners(WebApp.java:2246) at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:1040) at com.ibm.ws.webcontainer.webapp.WebApp.initialize(WebApp.java:6463) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApp(DynamicVirtualHost.java:446) at com.ibm.ws.webcontainer.osgi.DynamicVirtualHost.startWebApplication(DynamicVirtualHost.java:441) at com.ibm.ws.webcontainer.osgi.WebContainer.startWebApplication(WebContainer.java:1000) at com.ibm.ws.webcontainer.osgi.WebContainer.startModule(WebContainer.java:824) at com.ibm.ws.app.manager.web.internal.WebModuleHandlerImpl.deployModule(WebModuleHandlerImpl.java:103) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployModule(DeployedAppInfoBase.java:871) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployModules(DeployedAppInfoBase.java:831) at com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:818) at com.ibm.ws.app.manager.ear.internal.EARApplicationHandlerImpl.install(EARApplicationHandlerImpl.java:84) at com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:141) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1192) at com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:805) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) I'm trying to setup logging in an entangled ear app consisting of a bunch of separate war modules using SiftingAppender and JNDIBasedContextDiscriminator deployed to IBM Liberty. Can't reproduce it in simpler configuration. So far I've just removed all modules but one and start still invoked twice (the bp in AuthorisationListener.java:34 is triggered only once). Any help is highly appreciated. logback version is 1.1.7. Best regards, Eugene.

1 0

Using parameter markers and exceptions in non-Logback bindings
by Ti Strga 12 Jul '16

12 Jul '16

There's an entry in the FAQ at http://www.slf4j.org/faq.html#paramException asking how to parameterize a logging statement when also passing an exception. The FAQ explains that the API will automatically figure it out, as long as the last argument passed is the exception and not some other kind of object. (This would be nice to mention in the javadocs if feasible.) My question: the FAQ refers to SLF4J 1.6.0 and "the SLF4J API", but the only place I saw this actually implemented was in logback-classic (the LoggingEvent class in ch.qos.logback.classic.spi, not the LoggingEvent in org.slf4j.event). Are other implementations of the SLF4J API expected to provide the same behavior? Because the wording makes it sound like SLF4J is doing the work on behalf of the implementation, but obviously an interface class can't do that. :-) Am I just misinterpreting the FAQ? thanks, Ti

1 0

Avoid pre-initialization upon the first LoggerFactory.getILoggerFactory();
by Brice Dutheil 08 Jul '16

08 Jul '16

Hi, I would like share a single log configuration for two web-apps that run on the same container. Yet I want each web-app to log in separate files. I tried different approach the best one is actually very close to some solution I later found on the FAQ : http://logback.qos.ch/faq.html#sharedConfiguration LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerFactory(); JoranConfigurator jc = new JoranConfigurator(); jc.setContext(loggerContext); loggerContext.reset(); loggerContext.setName(appName); // use ${CONTEXT_NAME} in logback.xml jc.doConfigure(Objects.requireNonNull(source, "Logback configuration is missing")); However for operation reasons we pass the configuration via the system property logback.configurationFile, so what happens is that the first call to LoggerFactory.getILoggerFactory() initialise the LoggerContext and creates files with non initialised variables. As I’m using the context name, the file names have default in their name (this is the default value of the context name), if using variable I get a filename with my-var-name_IS_UNDEFINED. *The question is :* Is there proper way anyway to avoid this pre-initialisation to avoid creating this empty file ? I didn’t found any way to hook in the org.slf4j.LoggerFactory or org.slf4j.impl.StaticLoggerBinder (of logback-classic). — Brice

3 6

Question regarding appenders
by Jose Monreal Bailey 04 Jul '16

04 Jul '16

Good day everyone, Is it possible to have a Console Appender using an AsyncAppender? Does it make sense? I have an logback configuration that seems not to be working, and perhaps it's because of a misconfiguration. Regards, J

2 1

logback additivity level is not working
by Ted Smith 24 Jun '16

24 Jun '16

Hello: I have the following config <logger name="a.b.c.Klass" level="trace" additivity="true"> <appender-ref ref="aSiftAppenderUsingCustomMarker" /> </logger> <logger name="a.b" level="error" additivity="false"> <appender-ref ref="errorAppender" /> </logger> as you can see, I am trying to capture all "error" level messages (and discard lower levels) from child loggers into the "errorAppender", even though child loggers are at trace level, which would log to their own siftAppenders. But all the trace logs still get into error appenders, even though the level is clearly set to "error" Could it be due to the use of marker or siftappender in my log like log.trace(marker,message) but the error logger should still check the level and disregard any marker info. Thanks in advance for your help

2 2

Dynamically change a variable value for file location
by Douglas Moraes 24 Jun '16

24 Jun '16

Hi, I want to save my log file in a directory accordingly the current day. For example, if today is 0614 (June 14th), all log events will go to a folder 0614, and tomorrow I want the logs to go to 0615. I don´t want use rolling policy. I mean, I want the file to be directly created in the right place, and not saved in a temporary place and in other day to be saved in an archive place. I tryed: <configuration> <timestamp key="DIR" datePattern="MMdd" /> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>./log/${DIR}/gp2b.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>app.%i.log</fileNamePattern> <minIndex>1</minIndex> <maxIndex>10</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>5MB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36}:%L - %msg%rEx{10}%n</pattern> </encoder> </appender> <logger name="com.ocs.ProxyHttp.gp2b" level="DEBUG" /> <root level="DEBUG"> <appender-ref ref="FILE" /> </root> </configuration> Thanks, Douglas

2 3

GEventEvaluator/JaninoEventEvaluator filter doesn't work
by nagendra 21 Jun '16

21 Jun '16

Hi, I am trying to GEventEvaluator/JaninoEventEvaluator filter but expression is not working...it keeps print messages even condition is false. i am using groovy configuration. and logback 1.0.13 and janino 2.7.8. i am getting the following error in trace. 17:04:07,255 |-ERROR in ch.qos.logback.classic.gaffer.AppenderDelegate@12a94400 - Appender [SELM] of type [ch.qos.logback.core.ConsoleAppender] has no appplicable [EvaluatorFilter] property 17:04:07,265 |-ERROR in ch.qos.logback.classic.gaffer.AppenderDelegate@12a94400 - Unexpected argument type org.codehaus.groovy.runtime.NullObject 17:04:07,265 |-ERROR in ch.qos.logback.classic.gaffer.AppenderDelegate@12a94400 - No 'class' argument specified for [filter] in appender [SELM] of type [ch.qos.logback.core.ConsoleAppender] -------------------------------------------------------------- config file appender("SELM", ConsoleAppender) { filter(EvaluatorFilter) { evaluator(GEventEvaluator) { expression = '(e.mdc?.get("job_name").contains("selm") )' } onMismatch = DENY onMatch = NEUTRAL } encoder(PatternLayoutEncoder) { pattern = "%date %-5level [${pid}-${HOSTNAME} %thread] %logger{30} - %msg %ex{full}%n" } }

2 1

Multiple webapps, one shared external configuration file
by Thomas Meyer 20 Jun '16

20 Jun '16

Hi, I stumbled upon this SO http://stackoverflow.com/questions/10465301/tomcat-war-configure-logback-to… So is it a good idea to have multiple web apps all using the same config file? What is the potential drawback of above solution besides all app using the same default context? The last sentence "Such involuntary sharing of the same configuration by multiple repositories will result in corrupt log output." from http://logback.qos.ch/manual/contextSelector.html implies some problems but doesn't explain why. The underlying idea in log back seems to be this: Always package the config file in your app, if you need a different test config also put test log back config file into your test class path. Having multiple target environments with potentially different logging requirements doesn't fit above model and it would be good to externalise the log back config file. But sadly only one config file is supported with a system property. So what is the best solution for having multiple web apps on a tomcat and having multiple target environment with potential different logging requirements. What is a good solution pattern for this? PS: using the JNDI ContextSelector only seems to search in the web app itself for the config file. With kind regards Thomas Meyer

2 1

Re: [logback-user] Logback becomes excruciatingly slow during rollover
by Vesuvius Prime 26 May '16

26 May '16

Hello Ceki, Thank you for the suggestion. We added the debug="true" option and Logback gave us a clue about the problem: ERROR in ch.qos.logback.core.rolling.RollingFileAppender[DS_QUERY_PROFILE_FILE] - openFile(sD:/logs/query_profile_dataservice.log,true) call failed. java.io.FileNotFoundException: sD:\logs\query_profile_dataservice.log (The filename, directory name, or volume label syntax is incorrect) Apparently, when somebody modified the logging configuration, they added a redundant 's' at the beginning of the log file path. This caused Logback to fall back to letting that appender use the log file used by another appender. In the end, two different appenders started using the same log file (by using Process Explorer, we also saw that the same JVM was holding *two* handles to file D:\logs\product.log), and eventually, when Logback tried to roll over the log files, the problems started. We could see the following in the logs: Failed to rename file [D:\logs\product.log] to [D:\logs\product_0.log]. Normally, only one file handle to file D:\logs\product.log is used. When I added a similar 's' in a test environment, I got two file handles too, and eventually Logback became super-slow. We asked the customer to remove the redundant 's' and to restart the product and then to wait until the next roll-over and to tell us if things were okay. I just received the following feedback from our support people: "Customer has been running with new serviceability.xml file since last change. So far, it appears the files are rolling over and there is no longer any slowness once the file reaches 50mb. We'll continue to monitor thru next week, but it appears the issue may have been resolved by fixing the file." It will be great if Logback gets fixed, so that: 1. Two appenders should never write to the same file, or if they do, then the code should be fixed in such a way that this causes no problems 2. Logback should not become so slow. Perhaps some non-(b)locking algorithm should be used, if possible. Thank you for your help! ---------------------------------------------------------------------- Hello Vesuvius, Enabling logback's internal status messages [1] is an investigative step of *first* resort. I would start there. Any computing system can be brought to its knees if sufficiently stressed. From what I could gather from your previous messages, the application in question generates massive amounts of logs. If so, my suggestion would be to reduce logging output by setting the root logger level to WARN for example. As a side note, I would suggest using SizeAndTimeBasedRollingPolicy [2] which provides a much nicer archiving policy than the FixedWindowRollingPolicy+SizeBasedTriggeringPolicy combination. -- Ceki [1] http://logback.qos.ch/manual/configuration.html#automaticStatusPrinting [2] http://logback.qos.ch/manual/appenders.html#SizeAndTimeBasedRollingPolicy On 5/11/2016 12:02, Vesuvius Prime wrote: > Hi, > Thank you for the suggestion. This was the first thing I had > suggested to the customer during the live session with them but then > they said they didn't want to be a "testbed" for us, so they didn't do > it. Now I asked our support guys to ask the customer again to do this > and this time the customer agreed. After waiting a while for the logs > to roll over, here's the feedback: > > "Hello, Customer just provided an update. Log file is not rolling > over, however it has grown to over 90mb, but the [product] has not > slowed down." > > So, there's an improvement -- at least now we're not becoming > unusable due to excessive slowness. However, the log grows without a > limit. The bottom line is that this is an improvement, but not a > solution. > > I would still love somebody with deep knowledge of Logback > (presumably its authors) to provide some feedback here. For example, > if this is a known problem and it has been solved in some version of > Logback, we may go ahead an modify the Virgo server to use that > version. Alternatively, if Logback is unreliable, we may have to > switch to some other logging framework. I've been seeing various > reports about rollover problems, even in this mail list. We can't > afford to lose customers due to logging. Besides, this creates a > really bad image to Logback itself. > > Thank you for reading this. > ------------------------------ Message: 2 Date: Thu, 12 May 2016 08:25:56 +0100 From: David Roussel <nabble(a)diroussel.xsmail.com> To: logback users list <logback-user(a)qos.ch> Subject: Re: [logback-user] Change FixedWindowRollingPolicy rolling behaviour Message-ID: <1B78DD98-75AA-43AB-BEA5-D291673026C2(a)diroussel.xsmail.com> Content-Type: text/plain; charset=us-ascii Hi DK, It's not clear what you are asking for. Currently the files are renamed in reverse order so that there is no name clash. What other strategy are you suggesting? David > On 27 Apr 2016, at 15:05, DK <desmond.kirrane(a)gmail.com> wrote: > > Hi can I change FixedWindowRollingPolicy to rollover as follows: > > foo.log active log file > foo1.log first rollover > foo2.log second rollover > foo3.log third rollover > > Current behaviour is second rollover. foo1.log is renamed as foo2.log. > foo.log is renamed as foo1.log > > > > -- > View this message in context: http://logback.10977.n7.nabble.com/Change-FixedWindowRollingPolicy-rolling-… > Sent from the Users mailing list archive at Nabble.com. > _______________________________________________ > logback-user mailing list > logback-user(a)qos.ch > http://mailman.qos.ch/mailman/listinfo/logback-user ------------------------------ Subject: Digest Footer _______________________________________________ logback-user mailing list logback-user(a)qos.ch http://mailman.qos.ch/mailman/listinfo/logback-user ------------------------------ End of logback-user Digest, Vol 56, Issue 4 *******************************************

1 0

java.lang.classcircularityerror java/util/logging/logrecord
by Abhijit Kangale 23 May '16

23 May '16

Hi Team, I have configured logback.xml for my spring boot application. My spring boot version - 1.3.3.RELEASE, java version - 1.8 update 45, tomcat version - 8. I have put logback.xml file in my local tomcats /lib folder. Whenever I am running my tomcat without debug configuration it works fine. But whenever I am trying run tomcat server with debug configured in catalina.bat file (with this option - set "JAVA_OPTS=-Xdebug -Xrunjdwp:transport=dt_socket...... ) it displays java.lang.ClassCircularityError: java/util/logging/LogRecord and tomcat window closes. Detailed error trace : java.lang.ClassCircularityError: java/util/logging/LogRecord at org.slf4j.bridge.SLF4JBridgeHandler.getSLF4JLogger(SLF4JBridgeHandler.java: 200) at org.slf4j.bridge.SLF4JBridgeHandler.publish(SLF4JBridgeHandler.java:289) at java.util.logging.Logger.log(Logger.java:458) at java.util.logging.Logger.doLog(Logger.java:480) at java.util.logging.Logger.logp(Logger.java:596) I have tried all the solutions given in thread - http://stackoverflow.com/questions/2656565/classcircularityerror-when-runni…. But nothing is working. Can I get some pointers to resolve this issue? I have attached my logback.xml file. Thanks, Abhijit

1 1