qos-ch / logback-extensions Goto Github PK
View Code? Open in Web Editor NEWThe Logback Extensions project provides community supported extensions to the Logback logging framework.
License: Other
The Logback Extensions project provides community supported extensions to the Logback logging framework.
License: Other
I'm having the following issue with logback-ext-spring-0.1.2.jar on JDK 6
java version "1.6.0_27"
OpenJDK Runtime Environment (IcedTea6 1.12.6) (6b27-1.12.6-1ubuntu0.10.04.2)
OpenJDK 64-Bit Server VM (build 20.0-b12, mixed mode)
Stacktrace:
java.lang.UnsupportedClassVersionError: ch/qos/logback/ext/spring/web/LogbackConfigListener : Unsupported major.minor version 51.0 (unable to load class ch.qos.logback.ext.spring.web.LogbackConfigListener)
Can you support JDK 6 by updating maven-compiler-plugin plugin in pom.xml to support JDK 6? Something like
When the spring configuration location is specified as a file: URL if it isn't found then it causes an error. classpath: URLs fail gracefully because Spring's ResourceUtils.getURL()
throws a FileNotFoundException when the classpath URL can't be resolved. In contrast File URLs only cause that exception when they are invalid as both a URL and as a filepath (something that I was unable to do on a Mac running Java 8, perhaps windows is different).
File URLs should fail gracefully to allow the multiple configuration logic to behave properly, just like they do for classpath URLs.
Caused by: ch.qos.logback.core.joran.spi.JoranException: Could not open URL [file:/Users/foo/bar/logback.xml].
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.ext.spring.LogbackConfigurer.initLogging(Unknown Source)
... 94 more
Caused by: java.io.FileNotFoundException: /Users/foo/bar/logback.xml (No such file or directory)
at java.io.FileInputStream.open0(Native Method)
at java.io.FileInputStream.open(FileInputStream.java:195)
at java.io.FileInputStream.<init>(FileInputStream.java:138)
at java.io.FileInputStream.<init>(FileInputStream.java:93)
at sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:90)
at sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:188)
at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:48)
... 96 more
java.lang.ClassCastException: org.slf4j.impl.Log4jLoggerFactory cannot be cast to ch.qos.logback.classic.LoggerContext
at ch.qos.logback.ext.spring.LogbackConfigurer.initLogging(LogbackConfigurer.java:72)
at ch.qos.logback.ext.spring.web.WebLogbackConfigurer.initLogging(WebLogbackConfigurer.java:142)
at ch.qos.logback.ext.spring.web.LogbackConfigListener.contextInitialized(LogbackConfigListener.java:54)
at org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:782)
at org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:424)
at org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:774)
at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:249)
at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1242)
at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:717)
at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
at org.mortbay.jetty.plugin.JettyWebAppContext.doStart(JettyWebAppContext.java:298)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.doStart(ContextHandlerCollection.java:172)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerCollection.doStart(HandlerCollection.java:229)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:95)
at org.eclipse.jetty.server.Server.doStart(Server.java:282)
at org.mortbay.jetty.plugin.JettyServer.doStart(JettyServer.java:65)
at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
at org.mortbay.jetty.plugin.AbstractJettyMojo.startJetty(AbstractJettyMojo.java:520)
at org.mortbay.jetty.plugin.AbstractJettyMojo.execute(AbstractJettyMojo.java:365)
at org.mortbay.jetty.plugin.JettyRunMojo.execute(JettyRunMojo.java:523)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:106)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:318)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
at org.codehaus.classworlds.Launcher.main(Launcher.java:47)
2013-12-07 09:24:21.840:WARN:oejsh.RequestLogHandler:!RequestLog
MDC seems to be ignored in of LogglyBatchAppender
i.e
%X{mdcData}
I cloned the repository and tried to build with mvn install
. The logback-ext-spring
module builds as expected (after dealing with issues #18 and #19), but the logback-ext-loggly
module has a test failure:
sendsOnlyWhenMaxBucketsFull(ch.qos.logback.ext.loggly.LogglyBatchAppenderTest): expected:<4> but was:<3>
I've not dug too deep into this yet, but will continue to update the ticket as more information becomes available during the course of my investigation.
like we want to print some business log and separation from info.log, can't we expand log Level.
The Building page of the wiki does not mention that a GPG private key is required to run mvn install
.
Consider adding this to the docs and linking to a short tutorial on how to install the GPG library and generate a key.
On Mac OSX, it looks like this (assuming that Homebrew is installed):
brew install gpg
gpg --gen-key
Hello,
logback News page says Release 1.2.0 fixes a rather severe serialization vulnerability in SocketServer and ServerSocketReceiver. Users running these components should upgrade immediately. Therefore, could you make a new release with logback.version >= 1.2.0 ?
It is 1.1.1 currently :-(
I set up a LogglyBatchAppender to ship my logs off to Loggly with the following configuration:
<!-- loggly appender running in batch mode -->
<appender name="LOGGLY" class="ch.qos.logback.ext.loggly.LogglyBatchAppender">
<!-- with this notation, we can manually specify if logs should be reported over http for debugging or https for prod environments -->
<endpointUrl>http://logs-01.loggly.com/bulk/customer-key</endpointUrl>
<!-- format logs as JSON so that stack traces are preserved -->
<layout class="ch.qos.logback.contrib.json.classic.JsonLayout">
<jsonFormatter class="ch.qos.logback.contrib.jackson.JacksonJsonFormatter"/>
</layout>
<!-- performance tuning options -->
<maxNumberOfBuckets>8</maxNumberOfBuckets>
<maxBucketSizeInKilobytes>1024</maxBucketSizeInKilobytes>
<flushIntervalInSeconds>5</flushIntervalInSeconds>
</appender>
This works as expected, but when the logs arrive in Loggly, the entire batch is treated as a single event. Here is an example from Loggly's dashboard:
2014/02/25 21:26:03.213 UTC {"timestamp":"1393363558399","level":"INFO","thread":"main","logger":"org.springframework.web.context.ContextLoader","message":"Root WebApplicationContext: initialization started","context":"default"} {"timestamp":"1393363558484","level":"INFO","thread":"main","logger":"org.springframework.web.context.support.XmlWebApplicationContext","message":"Refreshing Root WebApplicationContext: startup date [Tue Feb 25 16:25:58 EST 2014]; root of context hierarchy","context":"default"} {"timestamp":"1393363558519","level":"INFO","thread":"main","logger":"org.springframework.beans.factory.xml.XmlBeanDefinitionReader","message":"Loading XML bean definitions from ServletContext resource [/WEB-INF/spring/applicationContext.xml]","context":"default"}
As you can see, this batch contains three separate log events, but Loggly treats them as a single event.
According to the Loggly documentation, individual log events must be separated by newline characters in the POST body of the request. I suspect that this is not being done in the encoder.
Upon adding the following to my pom.xml:
<dependency>
<groupId>org.logback-extensions</groupId>
<artifactId>logback-ext-loggly</artifactId>
<version>version</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback.contrib</groupId>
<artifactId>logback-json-classic</artifactId>
<version>version</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>ch.qos.logback.contrib</groupId>
<artifactId>logback-jackson</artifactId>
<version>version</version>
<scope>runtime</scope>
</dependency>
I got this error while running mvn clean install
:
Failed to execute goal on project webapp: Could not resolve dependencies for project webapp:webapp:war:0.1-SNAPSHOT: The following artifacts could not be resolved: org.logback-extensions:logback-ext-loggly:jar:version, ch.qos.logback.contrib:logback-json-classic:jar:version, ch.qos.logback.contrib:logback-jackson:jar:version: Could not find artifact org.logback-extensions:logback-ext-loggly:jar:version in labs-consol-release (http://labs.consol.de/maven/repository) -> [Help 1]
Seems like there might be a problem with the maven repository.
Link: https://github.com/qos-ch/logback-extensions/wiki/Spring
Hi,
I'm curious why the example is using static
keyword for all the beans. Is it used to save memory?
Compile dependencies are completely missing from the maven pom of release 0.1.5 of logback-ext-spring, resulting in NoClassDefFoundError in a maven project. See the pom:
http://central.maven.org/maven2/org/logback-extensions/logback-ext-spring/0.1.5/logback-ext-spring-0.1.5.pom
The ones from the build.gradle should be there.
Example of stacktrace:
java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException
at ch.qos.logback.ext.spring.web.LogbackConfigListener.contextInitialized(Unknown Source)
Would be useful if the artifacts of this project were published to Maven Central.
Could you please review this - described also here on Stackoverflow (http://stackoverflow.com/questions/30072388/logback-extensions-spring-integration-fileappender-not-working)
Mainly, everything works fine as you describe it until I try to make a RollingFileAppender work. Nothing happens. Here is my spring part for registration:
<!-- Logback Spring Initialization -->
<bean class="ch.qos.logback.ext.spring.ApplicationContextHolder" />
<bean id="fileAppender" class="ch.qos.logback.core.rolling.RollingFileAppender" init-method="start" destroy-method="stop">
<property name="context" value="#{ T(org.slf4j.LoggerFactory).getILoggerFactory() }" />
<property name="file" value="/logs/testlog.log"/>
<property name="append" value="true"/>
<property name="encoder">
<bean class="ch.qos.logback.classic.encoder.PatternLayoutEncoder" init-method="start" destroy-method="stop">
<property name="context" value="#{ T(org.slf4j.LoggerFactory).getILoggerFactory() }" />
<property name="pattern" value="%d{yyyy-MM-dd_HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n" />
</bean>
</property>
</bean>
Thanks for your support!
The current loggly bulk appender has some issues with conversion for log separation and json parsing. Manually changing the endpoint to https://logs-01.loggly.com/bulk/ seems to fix these issues.
As we still don't have a release 0.1.2
which includes the loggly hostname change, we can document the following workaround to set endpointUrl
instead of inputKey
as a workaround:
<appender name="logglyAppender" class="ch.qos.logback.ext.loggly.LogglyAppender">
<!-- <inputKey>YOUR_LOGGLY_INPUT_KEY_HERE</inputKey> -->
<endpointUrl>https://logs-01.loggly.com/inputs/YOUR_LOGGLY_INPUT_KEY_HERE</endpointUrl>
</appender>
You guys know better if this is a good idea and where is the best place.
When building the project for the first time, I got the following exception while running mvn install
:
java.lang.IllegalStateException: Native library for Attach API not available in this JRE
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:81)
at mockit.internal.startup.JDK6AgentLoader.loadAgent(JDK6AgentLoader.java:54)
at mockit.internal.startup.AgentInitialization.initializeAccordingToJDKVersion(AgentInitialization.java:21)
at mockit.internal.startup.Startup.initializeIfNeeded(Startup.java:96)
at mockit.internal.startup.Startup.initializeIfPossible(Startup.java:111)
at org.junit.runner.Runner.<clinit>(Runner.java:22)
at org.junit.internal.builders.JUnit4Builder.runnerForClass(JUnit4Builder.java:13)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.builders.AllDefaultPossibilitiesBuilder.runnerForClass(AllDefaultPossibilitiesBuilder.java:29)
at org.junit.runners.model.RunnerBuilder.safeRunnerForClass(RunnerBuilder.java:57)
at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:24)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:250)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189)
at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165)
at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75)
Caused by: java.lang.UnsatisfiedLinkError: sun.tools.attach.LinuxVirtualMachine.isLinuxThreads()Z
at sun.tools.attach.LinuxVirtualMachine.isLinuxThreads(Native Method)
at sun.tools.attach.LinuxVirtualMachine.<clinit>(LinuxVirtualMachine.java:364)
at mockit.internal.startup.JDK6AgentLoader.getVirtualMachineImplementationFromEmbeddedOnes(JDK6AgentLoader.java:71)
It looks like the JMockIt dependency requires Java's Attach API to function. As far as I can tell, it's necessary to add tools.jar to the classpath on Unix/Mac OSX systems. See this StackOverflow answer for details.
I've got a Spring application (not Spring Boot) where I've integrated logback-extensions in order to programatically configure appenders. For example, the console appender is only configured for the "dev" profile (as per the logback-extensions wiki page using a DelegatingLogbackAppender).
This works great except the case where there is an error during context initialization. Then, Spring seems to destroy the delegated appender before the final error message gets logged! (e.g. "ERROR org.springframework.web.context.ContextLoader - Context initialization failed" followed by a stack trace).
Is there any way to work around this limitation and somehow delay the destruction of this appender?
We are seeing deadlock issues where we are using LogglyAppender wrapped in an AsyncAppender. I was reviewing the LogglyAppender code to see if there's anything that might account for it there and noticed that connection.disconnect() is being called. From the Javadocs (http://docs.oracle.com/javase/7/docs/api/java/net/HttpURLConnection.html#disconnect()), it looks like it might be worth considering not calling disconnect as the docs suggest it is a hint to connection that "Indicates that other requests to the server are unlikely in the near future". It's unclear what effect calling disconnect() will have but it seems in a case like ours where we are sending logging entries to Loggly frequently that it might be causing us to incur unnecessary overhead.
I am working on Android native app and I have successfully integrated logback with LOGCAT and now trying to integrate it with loggly but I am getting some issue with it and I thought this is the best place to get guidance/resolution of it.
build.gradle :-
compile 'org.logback-extensions:logback-ext-loggly:0.1.2'
logback.xml :-
<configuration>
<appender name="LOGCAT" class="ch.qos.logback.classic.android.LogcatAppender">
<encoder>
<pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n</pattern>
</encoder>
</appender>
<appender name="LOGGLY" class="ch.qos.logback.ext.loggly.LogglyAppender">
<endpointUrl>
https://logs-01.loggly.com/inputs/d6415bd0-88f4-407d-8e89-bd9c4c95ef6f/tag/logback
</endpointUrl>
<encoder>
<pattern>%d{"ISO8601", UTC} %p %t %c{0}.%M - %m%n</pattern>
</encoder>
</appender>
<logger name="co.pointwise.android.sdk" level="debug" additivity="false">
<appender-ref ref="LOGGLY" />
</logger>
<root level="debug">
<appender-ref ref="LOGCAT" />
</root>
</configuration>
Full Error Log :-
08-12 09:19:21.663 27034-27034/co.librarytest I/art﹕ Late-enabling -Xcheck:jni
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,511 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [assets/logback.xml] at [assets/logback.xml]
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,618 |-INFO in ch.qos.logback.classic.joran.action.ConfigurationAction - debug attribute not set
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,619 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.classic.android.LogcatAppender]
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,622 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - Naming appender as [LOGCAT]
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,629 |-INFO in ch.qos.logback.core.joran.action.NestedComplexPropertyIA - Assuming default type [ch.qos.logback.classic.encoder.PatternLayoutEncoder] for [encoder] property
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,680 |-INFO in ch.qos.logback.core.joran.action.AppenderAction - About to instantiate appender of type [ch.qos.logback.ext.loggly.LogglyAppender]
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ 09:19:22,681 |-ERROR in ch.qos.logback.core.joran.action.AppenderAction - Could not create an Appender of type [ch.qos.logback.ext.loggly.LogglyAppender]. ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ at ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(Unknown Source)
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(Unknown Source)
08-12 09:19:22.707 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.action.AppenderAction.begin(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.EventPlayer.play(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.impl.StaticLoggerBinder.init(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.impl.StaticLoggerBinder.<clinit>(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at co.pointwise.android.sdk.db.JournalContentProvider.<init>(JournalContentProvider.java:30)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Constructor.newInstance(Native Method)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.Class.newInstance(Class.java:1572)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.installProvider(ActivityThread.java:5039)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.installContentProviders(ActivityThread.java:4646)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4586)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.access$1500(ActivityThread.java:148)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1353)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.os.Handler.dispatchMessage(Handler.java:102)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.os.Looper.loop(Looper.java:135)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.main(ActivityThread.java:5312)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Method.invoke(Native Method)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Method.invoke(Method.java:372)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:901)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:696)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ Caused by: java.lang.ClassNotFoundException: Didn't find class "ch.qos.logback.ext.loggly.LogglyAppender" on path: DexPathList[[zip file "/data/app/co.librarytest-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at ... 33 common frames omitted
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ 09:19:22,681 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@8:78 - ActionException in Action for tag [appender] ch.qos.logback.core.joran.spi.ActionException: ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at ch.qos.logback.core.joran.spi.ActionException: ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.action.AppenderAction.begin(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Unknown Source)
08-12 09:19:22.708 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.Interpreter.startElement(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.spi.EventPlayer.play(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.joran.GenericConfigurator.doConfigure(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.classic.util.ContextInitializer.autoConfig(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.impl.StaticLoggerBinder.init(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.impl.StaticLoggerBinder.<clinit>(Unknown Source)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:129)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:302)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:276)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at co.pointwise.android.sdk.db.JournalContentProvider.<init>(JournalContentProvider.java:30)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Constructor.newInstance(Native Method)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at java.lang.Class.newInstance(Class.java:1572)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.installProvider(ActivityThread.java:5039)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.installContentProviders(ActivityThread.java:4646)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.handleBindApplication(ActivityThread.java:4586)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.access$1500(ActivityThread.java:148)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread$H.handleMessage(ActivityThread.java:1353)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.os.Handler.dispatchMessage(Handler.java:102)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.os.Looper.loop(Looper.java:135)
08-12 09:19:22.709 27034-27034/co.librarytest I/System.out﹕ at at android.app.ActivityThread.main(ActivityThread.java:5312)
08-12 09:19:22.710 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Method.invoke(Native Method)
08-12 09:19:22.710 27034-27034/co.librarytest I/System.out﹕ at at java.lang.reflect.Method.invoke(Method.java:372)
08-12 09:19:22.710 27034-27034/co.librarytest I/System.out﹕ at at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:901)
08-12 09:19:22.710 27034-27034/co.librarytest I/System.out﹕ at at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:696)
08-12 09:19:22.710 27034-27034/co.librarytest I/System.out﹕ Caused by: ch.qos.logback.core.util.DynamicClassLoadingException: Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassNameAndParameter(Unknown Source)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(Unknown Source)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at ch.qos.logback.core.util.OptionHelper.instantiateByClassName(Unknown Source)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at ... 30 common frames omitted
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ Caused by: java.lang.ClassNotFoundException: Didn't find class "ch.qos.logback.ext.loggly.LogglyAppender" on path: DexPathList[[zip file "/data/app/co.librarytest-2/base.apk"],nativeLibraryDirectories=[/vendor/lib, /system/lib]]
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java:56)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at java.lang.ClassLoader.loadClass(ClassLoader.java:511)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at at java.lang.ClassLoader.loadClass(ClassLoader.java:469)
08-12 09:19:22.711 27034-27034/co.librarytest I/System.out﹕ at ... 33 common frames omitted
Any idea what is going wrong here?
Hi, I'm trying to use the Spring configuration example found here:
https://github.com/qos-ch/logback-extensions/wiki/Spring
But in the logback.xml you are referring to an appender that is not defined:
"<appender-ref ref="logbackAppender"/>" Get an error saying I have to define
lockbackAppender. If I'm instead using:
"<appender-ref ref="consoleAppender"/> the logback configuration gets ignored.
My spring config file looks the example
I am having hot deploy issues with jetty and logback-extensions. I can see the following error during hot deploy:
java.lang.NullPointerException
[Scanner-0] WARN org.eclipse.jetty.util.log - Unable to reach node goal: undeployed
java.lang.NullPointerException
at ch.qos.logback.ext.spring.LogbackConfigurer.shutdownLogging(Unknown Source)
at ch.qos.logback.ext.spring.web.WebLogbackConfigurer.shutdownLogging(Unknown Source)
at ch.qos.logback.ext.spring.web.LogbackConfigListener.contextDestroyed(Unknown Source)
at org.eclipse.jetty.server.handler.ContextHandler.doStop(ContextHandler.java:683)
at org.eclipse.jetty.servlet.ServletContextHandler.doStop(ServletContextHandler.java:143)
at org.eclipse.jetty.webapp.WebAppContext.doStop(WebAppContext.java:458)
at org.eclipse.jetty.util.component.AbstractLifeCycle.stop(AbstractLifeCycle.java:80)
at org.eclipse.jetty.deploy.bindings.StandardStopper.processBinding(StandardStopper.java:36)
at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:180)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:479)
at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:443)
at org.eclipse.jetty.deploy.DeploymentManager.removeApp(DeploymentManager.java:391)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileChanged(ScanningAppProvider.java:148)
at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileChanged(ScanningAppProvider.java:55)
at org.eclipse.jetty.util.Scanner.reportChange(Scanner.java:548)
at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:412)
at org.eclipse.jetty.util.Scanner.scan(Scanner.java:355)
at org.eclipse.jetty.util.Scanner$1.run(Scanner.java:306)
at java.util.TimerThread.mainLoop(Timer.java:567)
at java.util.TimerThread.run(Timer.java:517)
Any hints? I am running jetty 7.3.1.v20110307.
If we configure our webapp with WebLogbackConfigurer like this:
<context-param>
<description>
Location of the XML file that defines logback configuration - Applied by LogbackConfigListener.
</description>
<param-name>logbackConfigLocation</param-name>
<param-value>${WEBAPP_CONF_URI}/logging/logback.xml</param-value>
</context-param>
WebLogbakConfigurer tries to figure out if our configuration is an URI or not and only then it tries to resolve the placeholder and append to the real path whereas the placeholder is already a real path. Instead of doing so, it should first try to resolve the placeholder and if it is not a resource URI then it should append to the servlet real path as it is the case in Log4jWebConfigurer (from spring-web)
I find the source code of method onApplicationEnvironmentPreparedEvent in Spring Boot (1.3.1.RELEASE) would read properties(LOG_FILE, FILE_LOG_PATTERN .etc), which are referenced by logback.xml, from application.properties file, and then stop and reset the log configuration, could logback-extensions do the same thing?
if WebLogbackConfigurer use ServletContextPropertyUtils instead of SystemPropertyUtils like Log4jWebConfigurer to resolvePlaceholders is better
It mentions in the loggly documentation that this logger supports async mode:
https://www.loggly.com/docs/loggly-libraries-catalog/
I have been unable to determine however how to activate this async mode. A guide pointer to any existing documentation would be greatly appreciated.
Hey,
In the last two days I tried to use your LogglyBatchAppender instead of LogglyAppender with no success.
I found my problem just now:
On the 'logback.xml' I used the 'inputKey' tag for declaring my Loggly token and tags.
After a lot of searching I found this post that helped me to understand that I should prefer use the 'endpointUrl' tag instead of 'inputKey' tag to specify the route of 'bulk' instead of 'inputs' in the URL between the domain and my token, examples:
* BAD: <endpointUrl>https://logs-01.loggly.com/inputs/TOKEN/tag/TAGS</endpointUrl>
* GOOD: <endpointUrl>https://logs-01.loggly.com/bulk/TOKEN/tag/TAGS</endpointUrl>
My request for you is to improve the description of property 'endpointUrl' here to use 'bulk' instead of 'inputs' while using Batch Mode.
I hope it'd help a lot of people.
Thanks,
Amit.
I am getting the following exception while working with logglybatchappender
17:59:40,552 |-ERROR in loggly.async.LogglyBatchAppender[loggly] - LogglyAppender client-side exception java.net.SocketTimeoutException: Read timed out at java.net.SocketTimeoutException: Read timed out at at java.net.SocketInputStream.socketRead0(Native Method) at at java.net.SocketInputStream.read(Unknown Source) at at java.net.SocketInputStream.read(Unknown Source) at at sun.security.ssl.InputRecord.readFully(Unknown Source) at at sun.security.ssl.InputRecord.read(Unknown Source) at at sun.security.ssl.SSLSocketImpl.readRecord(Unknown Source) at at sun.security.ssl.SSLSocketImpl.readDataRecord(Unknown Source) at at sun.security.ssl.AppInputStream.read(Unknown Source) at at java.io.BufferedInputStream.fill(Unknown Source) at at java.io.BufferedInputStream.read1(Unknown Source) at at java.io.BufferedInputStream.read(Unknown Source) at at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source) at at sun.net.www.http.HttpClient.parseHTTP(Unknown Source) at at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source) at at java.net.HttpURLConnection.getResponseCode(Unknown Source) at at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(Unknown Source) at at loggly.async.LogglyBatchAppender.processLogEntries(LogglyBatchAppender.java:345) at at loggly.async.LogglyBatchAppender.processLogEntries(LogglyBatchAppender.java:297) at at loggly.async.LogglyBatchAppender$LogglyExporter.run(LogglyBatchAppender.java:448) at at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at at java.util.concurrent.FutureTask.runAndReset(Unknown Source) at at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source) at at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source) at at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at at java.lang.Thread.run(Unknown Source)
I am using following configuration in logback.xml
<configuration scan="true" scanPeriod="30 seconds" debug="true">
<appender name="loggly" class="ch.qos.logback.ext.loggly.LogglyBatchAppender">
<endpointUrl>https://logs-01.loggly.com/bulk/customer-token/tag/LogBack
</endpointUrl>
<pattern>%d{"ISO8601", UTC} %p %t %c{0}.%M - %m%n</pattern>
<debug>${logback.loggly.debug:-false}</debug>
</appender>
<root level="INFO">
<appender-ref ref="loggly"></appender-ref>
</root>
</configuration>
Getting "Warning: Class 'ch.qos.logback.ext.loggly.LogglyAppender' contains multiple setters for the same property 'proxyPort'." on startup.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.