Enrico Medves (JIRA | 25 May 09:35 2015
Picon

[JIRA] (LOGBACK-1066) cannot close files with SiftingAppender

We did something similar:

public class MySiftAppender extends SiftingAppender { <at> Override protected void append(ILoggingEvent event) { super.append(event); eventMarksEndOfLife(event); } protected boolean eventMarksEndOfLife(ILoggingEvent event) { Marker marker = event.getMarker(); if (marker == null) return false; boolean retValue = marker.contains(ClassicConstants.FINALIZE_SESSION_MARKER); if (retValue) { String discriminatingValue = getDiscriminator().getDiscriminatingValue(event); getAppenderTracker().stopAndRemoveNow(discriminatingValue); } return retValue; } }

Did you test your code? I'm not sure if the issue is related to adding appenders to the stale list or closing the staled appenders.
Anyway as soon as the file is closed, that appender won't log anything else. Setting timeout to 0 looks odd. Do you want to log a single line every file? If that's the case you could just send the FINALIZE marker after every log, even by overriding all logging methods.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Alexander Kitaev (JIRA | 24 May 23:26 2015
Picon

[JIRA] (LOGBACK-1072) Allow to set ClassLoader on GenericConfigurator

Issue Type: New Feature
Affects Versions: 1.0.13
Assignee: Logback dev list
Created: 24/May/15 11:25 PM
Description:

1) Host app uses logback, loads JoranConfigurator and configures logback
2) Host app loads plugin jar with a plugin classloader
3) Plugin loads its own logback.xml and would like to extend existing LoggingContext with plugin logging configuration and to use custom appender specified in pluging logback.xml
4) JoranConfigurator fails, as it fails to load plugin's appender.

There should be a way to specify classloader for JoranConfigurator or for individual configure calls. Configurator then should use specified classloader to load classes referenced in configuration file.

Project: logback
Priority: Major
Reporter: Alexander Kitaev
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Alexander Kitaev (JIRA | 24 May 23:20 2015
Picon

[JIRA] (LOGBACK-1066) cannot close files with SiftingAppender

I also ended up with extending SiftingAppender:

private static class ClosingSiftingAppender extends SiftingAppender { <at> Override protected void append(ILoggingEvent event) { super.append(event); if (eventMarksEndOfLife(event)) { getAppenderTracker().removeStaleComponents(Long.MAX_VALUE); } } }

Even if SiftingAppender would work (I suspect it doesn't because of a combination of timeout I've specified, frequency of the FINALIZE_SESSION markers sent, and actual append calls), it would not fit my needs as in our app we actually need to close the appender immediately, without any lingering or timeout.

I'd suggest to support this (immediate close) when timeout option is set to 0.

Another issue I've ran into is that JoranConfigurator uses its own ClassLoader to load classes, and as our code is a plugin loaded by a host app and JoranConfigurator is used by the host app and is already loaded, I couldn't specify a custom appender in the logback.xml and have to configure Loggers at runtime, programmatically.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Enrico Medves (JIRA | 23 May 14:32 2015
Picon

[JIRA] (LOGBACK-1066) cannot close files with SiftingAppender

I looked into the source code, I made my own sifting appender forcing close on the current appender file with the FINALIZE_SESSION_MARKER, but I hadn't much time to spend on it. It's just a temporarily solution but without that feature sifting appender is quite unusable. If you are interested i will post my code as soon as it's tested properly.
Timeout should also be fixed, but i was unable to find the bug yet. I saw it should stale unused appenders and later close them and the respective files.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Alexander Kitaev (JIRA | 23 May 02:32 2015
Picon

[JIRA] (LOGBACK-1066) cannot close files with SiftingAppender

I experince the same issue. Did you manage to resolve it?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Anindita Ghatak | 21 May 15:25 2015
Picon

Need your suggestion on logback vs log4j2

Hi,
I have done a poc for MDC Akka support with logback.MDC was not working with Akka and log4j.
I am planing to use log back.There is log4j2 also exists.Can you please suggest me which one is better logback or log4j2 ? Can you please give me an comparison list?

Thanks & Regards,
Anindita
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Axel Fontaine (JIRA | 20 May 17:59 2015
Picon

[JIRA] (LOGBACK-1071) Java 8 compact3 profile compatibility

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Axel Fontaine (JIRA | 20 May 17:57 2015
Picon

[JIRA] (LOGBACK-1071) Java 8 compact3 profile compatibility

java.beans in not used in many places. If the code is replaced by reflection code to call the necessary getters & setters, it should continue to work unchanged.

Usages: https://github.com/qos-ch/logback/search?utf8=%E2%9C%93&q=java.beans

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Ceki Gulcu (JIRA | 20 May 17:53 2015
Picon

[JIRA] (LOGBACK-1071) Java 8 compact3 profile compatibility

Ceki Gulcu commented on LOGBACK-1071

Can you be more specific?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Axel Fontaine (JIRA | 20 May 11:19 2015
Picon

[JIRA] (LOGBACK-1071) Java 8 compact3 profile compatibility

Issue Type: Improvement
Affects Versions: 1.1.3
Assignee: Logback dev list
Components: logback-classic, logback-core
Created: 20/May/15 11:19 AM
Description:

Currently logback relies on java.beans to parse its config and set properties on beans. The java.beans package is tied to AWT and not part of the compact profiles. It would be great to remove the dependency on java.beans to have access to Logback for applications using the compact profiles.

Project: logback
Labels: properties system
Priority: Major
Reporter: Axel Fontaine
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Paul Pogonyshev (JIRA | 20 May 10:32 2015
Picon

[JIRA] (LOGBACK-1070) Logback doesn't use Throwable.printStackTrace(), thus not allowing exceptions to inject their own information into stacktrace

Issue Type: Bug
Affects Versions: 1.1.3
Assignee: Logback dev list
Components: logback-classic
Created: 20/May/15 10:32 AM
Description:

As can be seen from file ThrowableProxyConverter, Logback doesn't call exception's printStackTrace() method, but uses some custom stacktrace dumping procedure. This appears just fine for standard exceptions, but the problem is, this method is not final and can be overriden. As a result, for certain exceptions results of "standard" stacktrace dumping and Logback output differ.

Usecase important for me is Jython exceptions. They splice Python stacktrace into Java stacktrace by overriding printStackTrace().

For comparison, here are parts of the same exception stacktrace. How it appears with exception.printStackTrace (...):

...
at java.lang.Thread.run(Thread.java:745)
Caused by: Traceback (most recent call last):
File "<string>", line 1, in <module>
File "test.py", line 3, in main
ValueError: this is a test error

at org.python.core.PyException.doRaise(PyException.java:219)
at org.python.core.Py.makeException(Py.java:1166)
...

How it appears in log file:

at java.lang.Thread.run(Thread.java:745)
Caused by: org.python.core.PyException: null
at org.python.core.PyException.doRaise(PyException.java:219)
at org.python.core.Py.makeException(Py.java:1166)
...

Logback probably does it for performance reasons, but in this case, for me at least, full stacktrace is infinitely more important than performance, because exceptions don't happen often anyway.

Project: logback
Priority: Major
Reporter: Paul Pogonyshev
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev

Gmane