link-nv / logback-s3-rolling-policy Goto Github PK

Hi
I got an compilation error : S3TimeBasedRollingPolicy.java:158: error: cannot find symbol [ERROR] if (future != null) { [ERROR] ^ [ERROR] [ERROR] could not parse error message: symbol: variable future [ERROR] location: class S3TimeBasedRollingPolicy<E>

Were the artifacts removed from the repository? I can't seem to find them here: http://repo.linkid.be/releases/

Hello guys,

Could you please clarify your license policy regarding usage of logback-s3-rolling-policy in other projects.
As I see you've attached Apache 2 license to GitHub project: https://github.com/link-nv/logback-s3-rolling-policy/blob/master/LICENSE.txt

But here

https://github.com/link-nv/logback-s3-rolling-policy/blob/master/src/main/java/ch/qos/logback/core/rolling/data/CustomData.java

you have another license information

/*
 * SafeOnline project.
 *
 * Copyright 2006-2013 Lin.k N.V. All rights reserved.
 * Lin.k N.V. proprietary/confidential. Use is subject to license terms.
 */

So the question - can we use it in our (closed source) project?

Thanks in advance

http://repo.linkid.be/releases is down..
Could you up your server or create another repo.

Thanks.

Would it be possible to upgrade the logger version as the latest aren't backwards compatible with the currently used version?

Hello, My project uses aws-sdk-java by this library and another library.
The other library needs to use aws-sdk-java version 1.10.
so I want it to be updated aws-sdk-java version.
https://github.com/link-nv/logback-s3-rolling-policy/blob/master/pom.xml#L65

awsAccessKey and awsSecretKey are documented as mandatory. It feels like a bad practice from security perspective.

Is there any specific reason why it wouldn't work with AWS SDK default credential provider chain?

When I go to the repo URL - http://repo.linkid.be/releases - it looks like the domain has been let go and it no longer holds a nexus repo. Does this live somewhere else? Also the version in the readme can be bumped to the newest one.

Thanks

Hi,

I wanted to rely on your appender, but the repository maven on which you publicly distribute your release is no more available.

Do you think you can publish it somewhere else? Or should I start from your source and build it in a local maven repository?

Regards

Hey,
we wanted to use this library in a play 2.5 application but it crashes when it tries to upload the files:

Exception in thread "pool-64-thread-1" java.lang.NoSuchFieldError: future
	at ch.qos.logback.core.rolling.S3TimeBasedRollingPolicy.waitForAsynchronousJobToStop(S3TimeBasedRollingPolicy.java:158)
	at ch.qos.logback.core.rolling.S3TimeBasedRollingPolicy.access$000(S3TimeBasedRollingPolicy.java:37)
	at ch.qos.logback.core.rolling.S3TimeBasedRollingPolicy$UploadQueuer.run(S3TimeBasedRollingPolicy.java:212)
	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)

By looking at the code it seems valid because "future" does not exist.

It looks like the S3TimeBasedRollingPolicy does not work as expected. When App shuts down, it leaves the last log file as a .tmp file and does not compress it as expected.
Example appender configuration

 <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
                <file>logs/myapp.csv</file>
                <encoder>
                    <pattern>%d{"yyyy-MM-dd HH:mm:ss.SSSSSSSSS"},%msg%n</pattern>
                </encoder>
                <rollingPolicy class="ch.qos.logback.core.rolling.S3TimeBasedRollingPolicy">
                    <!-- Rollover every hour-->
                    <fileNamePattern>logs/accountID=${accountID}/audit.%d{yyyy-MM-dd_HH}.%i.csv.gz</fileNamePattern>
                    <totalSizeCap>4000KB</totalSizeCap>
                    <s3BucketName>dev</s3BucketName>
                    <s3FolderName>test-buck</s3FolderName>
                    <rolloverOnExit>true</rolloverOnExit>
                    <shutdownHookType>JVM_SHUTDOWN_HOOK</shutdownHookType>
                    <prefixTimestamp>false</prefixTimestamp>
                    <prefixIdentifier>true</prefixIdentifier>
                    <timeBasedFileNamingAndTriggeringPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedFNATP">
                        <maxFileSize>10KB</maxFileSize>
                    </timeBasedFileNamingAndTriggeringPolicy>
                </rollingPolicy>
            </appender>

It should have rolled up the file Index and created a gz , but it didn't seem to have incremented the fileNameCounter or compressed it. Can someone confirm that this seems like a valid issue ? Have been looking in the code but actual process debugging is hard to capture to know what happens when onShutDown() calls the rollover() function.

I would like to use this policy for Minio (https://www.minio.io) which is an AWS S3 compatible implementation. Therefor I need to set another Endpoint in the configuration.

My approach was to add a getter/setter to the S3TimeBasedRollingPolicy and also add the according configuration element. But it is not picked up from the configuration like the bucket or s3 folder name.

I get the follow error messages in the logs:
15:45:01,232 |-ERROR in ch.qos.logback.core.joran.spi.Interpreter@38:19 - no applicable action for [s3Endpoint], current ElementPath is [[configuration][appender][rollingPolicy][s3Endpoint]]

How is the magic for picking up the configuration and adding it via a setter to the class working?

I am getting periodically this error if the the max file size is set to something low like 10KB. It feels like some sort of race condition.

Hi guys, I see logback provides different types of Appenders as configuration in logback.xml. So, just asking before I give it a try:
Would you happen to know of I can do something like, using a Sift Appender for using dynamic discriminator for dynamic file creations and using S3FixedSized Rolling policy in combination for pushing those dynamic files out to S3 ?
Something like this, using the incoming request's sessionID to create log files per session using your rolling S3 appender to upload those to S3 bucket with sessionID as bucket keys.