qos-ch / logback-extensions

The Logback Extensions project provides community supported extensions to the Logback logging framework.

logback-extensions

^v0.1.5

https://github.com/qos-ch/logback-extensions/wiki

Build Instructions

Run the following command to build:

./gradlew clean assemble

License

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.

logback-extensions's Issues

Maven compile dependencies missing from pom of v0.1.5

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)

Using Async Mode

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.

Could logback configuration file use properties resolved by spring?

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?

RollingFileAppender throws NullPointerException

%X{mdcData} not recognized in <pattern>

MDC seems to be ignored in of LogglyBatchAppender

i.e
%X{mdcData}

Artifacts Could Not Be Resolved

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.

Resolve system property placeholders before potentially resolving a real path.

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)

possible reload issue

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.

Bulk upload issue with loggly appender

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.

Failed to instantiate type ch.qos.logback.ext.loggly.LogglyAppender in Android

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 [email protected]: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?

logback-ext-loggly Build Fails with Test Failures

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.

can't we expand log Level.

like we want to print some business log and separation from info.log, can't we expand log Level.

Improve your wiki

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.

Publish to Maven Central

Would be useful if the artifacts of this project were published to Maven Central.

if WebLogbackConfigurer use ServletContextPropertyUtils like Log4jWebConfigurer to resolvePlaceholders is better

if WebLogbackConfigurer use ServletContextPropertyUtils instead of SystemPropertyUtils like Log4jWebConfigurer to resolvePlaceholders is better

"Using Spring Java Config" Example in Wiki

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?

Build Page Docs Don't Mention GPG Requirement

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
• Accept default configuration, fill in name, email address, and password
• When prompted for GPG password during build, enter the password for the key that you generated.

LogglyBatchAppender - Every line in stack trace is going as a separate log entry.

I am using the LogglyBatchAppender , but every line in the stack trace is showing up as a separate log entry.

RollingFileAppender not working

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!

Warning: Class 'ch.qos.logback.ext.loggly.LogglyAppender' contains multiple setters for the same property 'proxyPort'.

Getting "Warning: Class 'ch.qos.logback.ext.loggly.LogglyAppender' contains multiple setters for the same property 'proxyPort'." on startup.

Severe vulnerability requires logback version upgrade

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 :-(

Building Docs Don't Mention tools.jar Dependency

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.

Spring configuration problem

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

Consider not calling disconnect on the connection in LogglyAppender

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.

Log Events Sent in Batch Mode are not Recognized as Individual Events by Loggly

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.

there is an error!

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

DelegatingLogbackAppender shut down too early

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?

Configuration locations for Spring do not allow missing for file URLs

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

Document loggly hostname change workaround while we don't have 0.1.2

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.

Getting LogglyAppender client-side exception while using loggly Bulk mode.

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>

Cannot load LogbackConfigListener on JDK 6

I'm having the following issue with logback-ext-spring-0.1.2.jar on JDK 6

java -version

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
1.6
1.6