March 2009 - logback-dev - mailman3.qos.ch

[JIRA] Commented: (LBCORE-45) introduce FlushableAppender
by Ceki Gulcu (JIRA) 05 Mar '09

05 Mar '09

[ http://jira.qos.ch/browse/LBCORE-45?page=com.atlassian.jira.plugin.system.i… ] Ceki Gulcu commented on LBCORE-45: ---------------------------------- Hello Bruno, How about of flushing was a settable policy of WriteAppender? You could set the FlushingPolicy of a WriterAppender or any derived class which would allow you to flush the underlying output stream according to any criteria you choose. We could easily imagine a policy flushing on every warning or error in addition to special markers. For example, Marker FLUSH = MarkerFactory.getMarker("FLUSH"); logger.info(FLUSH, "finished serving request {}", request.getId()); In addition, we could have the writer appender instance pass its underlying output stream to the flushing policy so that you could explicitly flush it from within Spring. Would that work for you? > introduce FlushableAppender > --------------------------- > > Key: LBCORE-45 > URL: http://jira.qos.ch/browse/LBCORE-45 > Project: logback-core > Issue Type: Improvement > Components: Appender > Affects Versions: unspecified > Environment: Operating System: Linux > Platform: PC > Reporter: Bruno Navert > Assignee: Logback dev list > Priority: Minor > > Suggest a new sub-interface of Appender: > public interface FlushableAppender<E> extends Appender<E>, java.io.Flushable > { > } > Then, WriterAppender could be defined to implement FlushableAppender, with this simple implementation: > public void flush() throws IOException > { > writer.flush(); > } > This would allow manual flushing of the appenders. This is particularly useful when buffered IO is used, obviously. It allows, for instance, to manually flush all appenders when a request has been fully processed, ensuring that we retain the benefits of buffered IO while also having the full logs after request processing. > Here's sample code I used to get all appenders (run once after Logback configuration): > public static Set<Appender> getAllAppenders() > { > ContextSelector selector = StaticLoggerBinder.SINGLETON.getContextSelector(); > LoggerContext loggerContext = selector.getLoggerContext(); > Map<String, Appender> appenders = newHashMap(); > // loop through all Loggers > for ( Logger logger : loggerContext.getLoggerList() ) > { > // for each logger, loop through all its appenders > Iterator iter = logger.iteratorForAppenders(); > while ( iter.hasNext() ) > { > // appenders are uniquely identified by name, so store them in the Map thus > // this will overwrite the same entry in the Map many times (with the same reference) > Appender appender = ( Appender ) iter.next(); > appenders.put( appender.getName(), appender ); > } > } > return newHashSet( appenders.values() ); > } > The below bean is used in Spring, calling flush() forces all appenders to be flushed: > public class LogbackFlushBean implements Flushable > { > protected final Logger log = LoggerFactory.getLogger( getClass() ); > private final Collection<FlushableAppender> flushableAppenders = newLinkedList(); > @PostConstruct > public void loadFlushableAppenders() > { > for ( Appender appender : LogbackConfigurer.getAllAppenders() ) > { > if ( appender instanceof FlushableAppender ) > { > flushableAppenders.add( ( FlushableAppender ) appender ); > } > else > { > log.debug( "appender {} is not Flushable, skipping", appender.getName() ); > } > } > } > public void flush() throws IOException > { > for ( FlushableAppender appender : flushableAppenders ) > { > log.debug( "flushing appender {}", appender.getName() ); > appender.flush(); > } > } > } -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

[JIRA] Resolved: (LBCLASSIC-46) ThrowableInformation should keep the Throwable cause hierarchy intact.
by Ceki Gulcu (JIRA) 05 Mar '09

05 Mar '09

[ http://jira.qos.ch/browse/LBCLASSIC-46?page=com.atlassian.jira.plugin.syste… ] Ceki Gulcu resolved LBCLASSIC-46. --------------------------------- Fix Version/s: 0.9.16 Resolution: Fixed Issue has been recently fixed. > ThrowableInformation should keep the Throwable cause hierarchy intact. > ---------------------------------------------------------------------- > > Key: LBCLASSIC-46 > URL: http://jira.qos.ch/browse/LBCLASSIC-46 > Project: logback-classic > Issue Type: Improvement > Components: Other > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Joern Huxhorn > Assignee: Logback dev list > Priority: Minor > Fix For: 0.9.16 > > > Instead of a String representation of the whole Throwable stack trace incl. cause ThrowableInformation should instead look like this: > public class ThrowableInformation implements Serializable > { > String throwableClassName; > String message; > StackTraceElement[] stackTrace; > ThrowableInformation cause; > } > I omitted get/set and private in this example. > StackTraceElement is perfectly Serializable and did also receive a public c'tor in Java 5 so I guess that the current ThrowableInformation is more or less a relict of log4j which had to stay compatible with older Java versions. > You could obviously keep the getThrowableStrRep() method for compatibility. > This bug is somewhat related to LBCLASSIC-45 because I think that ThrowableInformation should also, as LoggingEvent, be just a dumb data container with no real logic. > The logic to extract the relevant StackTraceElements should IMHO be moved either into Logger or into a static factory method of ThrowableInformation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

svn commit: r2181 - in logback/trunk: logback-classic/src/main/java/ch/qos/logback/classic/sift logback-core/src/main/java/ch/qos/logback/core/sift
by noreply.ceki＠qos.ch 05 Mar '09

05 Mar '09

Author: ceki Date: Thu Mar 5 17:58:27 2009 New Revision: 2181 Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/AppenderFactory.java logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/MDCBasedDiscriminator.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderFactoryBase.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/Discriminator.java logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java Log: - cosmetic changes in variable names Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/AppenderFactory.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/AppenderFactory.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/AppenderFactory.java Thu Mar 5 17:58:27 2009 @@ -19,15 +19,15 @@ public class AppenderFactory extends AppenderFactoryBase<ILoggingEvent>{ - String mdcKey; + String key; - AppenderFactory(Context context, List<SaxEvent> eventList, String mdcKey) { + AppenderFactory(Context context, List<SaxEvent> eventList, String key) { super(context, eventList); - this.mdcKey = mdcKey; + this.key = key; } - public SiftingJoranConfiguratorBase<ILoggingEvent> getSiftingJoranConfigurator(String k) { - return new SiftingJoranConfigurator(mdcKey, k); + public SiftingJoranConfiguratorBase<ILoggingEvent> getSiftingJoranConfigurator(String discriminatingValue) { + return new SiftingJoranConfigurator(key, discriminatingValue); } } Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/MDCBasedDiscriminator.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/MDCBasedDiscriminator.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/sift/MDCBasedDiscriminator.java Thu Mar 5 17:58:27 2009 @@ -36,7 +36,7 @@ } /** - * Return the value associated with an MDC entry desginated by the Key + * Return the value associated with an MDC entry designated by the Key * property. If that value is null, then return the value assigned to the * DefaultValue property. */ Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderFactoryBase.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderFactoryBase.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/AppenderFactoryBase.java Thu Mar 5 17:58:27 2009 @@ -36,8 +36,8 @@ public abstract SiftingJoranConfiguratorBase<E> getSiftingJoranConfigurator(String k); - Appender<E> buildAppender(Context context, String k) throws JoranException { - SiftingJoranConfiguratorBase<E> sjc = getSiftingJoranConfigurator(k); + Appender<E> buildAppender(Context context, String discriminatingValue) throws JoranException { + SiftingJoranConfiguratorBase<E> sjc = getSiftingJoranConfigurator(discriminatingValue); sjc.setContext(context); sjc.doConfigure(eventList); return sjc.getAppender(); Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/Discriminator.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/Discriminator.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/Discriminator.java Thu Mar 5 17:58:27 2009 @@ -11,8 +11,30 @@ import ch.qos.logback.core.spi.LifeCycle; - +/** + * Implement this interface in order to compute a discriminating value for a + * given event of type <E>. + * + * <p>The returned value can depend on any data available at the time of the + * call, including data contained within the currently running thread. + * + * @author Ceki Gülcü + * + * @param <E> + */ public interface Discriminator<E> extends LifeCycle { + + /** + * Given event 'e' return a discriminating value. + * + * @param e + * @return + */ String getDiscriminatingValue(E e); + + /** + * + * @return + */ String getKey(); } Modified: logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java ============================================================================== --- logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java (original) +++ logback/trunk/logback-core/src/main/java/ch/qos/logback/core/sift/SiftingAppenderBase.java Thu Mar 5 17:58:27 2009 @@ -65,19 +65,19 @@ return; } - String value = discriminator.getDiscriminatingValue(event); + String discriminatingValue = discriminator.getDiscriminatingValue(event); long timestamp = getTimestamp(event); - Appender<E> appender = appenderTracker.get(value, timestamp); + Appender<E> appender = appenderTracker.get(discriminatingValue, timestamp); if (appender == null) { try { - appender = appenderFactory.buildAppender(context, value); + appender = appenderFactory.buildAppender(context, discriminatingValue); if (appender != null) { - appenderTracker.put(value, appender, timestamp); + appenderTracker.put(discriminatingValue, appender, timestamp); } } catch (JoranException e) { - addError("Failed to build appender for [" + value + "]", e); + addError("Failed to build appender for [" + discriminatingValue + "]", e); return; } }

1 0

svn commit: r2180 - logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/corpusTest
by noreply.ceki＠qos.ch 04 Mar '09

04 Mar '09

Author: ceki Date: Wed Mar 4 21:21:33 2009 New Revision: 2180 Modified: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/corpusTest/RandomUtilTest.java Log: make the unit test pass Modified: logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/corpusTest/RandomUtilTest.java ============================================================================== --- logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/corpusTest/RandomUtilTest.java (original) +++ logback/trunk/logback-classic/src/test/java/ch/qos/logback/classic/corpusTest/RandomUtilTest.java Wed Mar 4 21:21:33 2009 @@ -4,13 +4,19 @@ import java.util.Random; +import org.junit.Before; import org.junit.Test; import ch.qos.logback.classic.corpus.RandomUtil; public class RandomUtilTest { - + long now = System.currentTimeMillis(); + + @Before + public void setup() { + System.out.println(RandomUtilTest.class.getName()+" now="+now); + } @Test public void smoke() { @@ -18,7 +24,8 @@ int EXPECTED_AVERAGE = 6; int EXPECTED_STD_DEVIATION = 3; - long now = System.currentTimeMillis(); + + System.out.println(); Random r = new Random(now); int len = 3000; int[] valArray = new int[len]; @@ -26,10 +33,8 @@ valArray[i] = RandomUtil.gaussianAsPositiveInt(r, EXPECTED_AVERAGE, EXPECTED_STD_DEVIATION); } double avg = average(valArray); - for(int x: valArray) { - System.out.println(""+x); - } - assertEquals(EXPECTED_AVERAGE, avg, 0.1); + + assertEquals(EXPECTED_AVERAGE, avg, 0.3); } public double average(int[] va) {

1 0

how to get appender-ref list via Joran
by Cheenu 03 Mar '09

03 Mar '09

I am trying to develop a new appender for Async logging - a non- blocking appender similar to http://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/AsyncAppender.… Config is like: <appender name="async" class="logback.AsyncAppender"> <bufferSize>20</bufferSize> <appender-ref ref="stdout" /> <appender-ref ref="file" /> </appender> Question: How do I get list of appenders (the appender-ref's) in my code? Thanks

2 2

RFC: LoggingEvent redesign
by Ceki Gulcu 03 Mar '09

03 Mar '09

Hello all, I would like to split/redesign the LoggingEvent object as follows: interface ILoggingEvent { String[] getArgumentArray(); CallerData[] getCallerData(); Level getLevel(); String getLoggerName(); Marker getMarker(); Map<String, String> getMDCPropertyMap(); String getMessage(); String getThreadName(); ThrowableDataPoint[] getThrowableDataPointArray(); long getTimeStamp(); void setArgumentArray(Object[]) // other setters omitted } // localized usage, temporary lifespan class LoggingEvent implements ILoggingEvent { // getter and setter methods from ILoggingEvent omitted void prepareForDeferredProcessing(); // create a LoggingEventMemento image of this LoggingEvent LoggingEventMemento asLoggingEventMemento(); } // distributed (or remote) usage, long term lifespan class LoggingEventMemento implements ILoggingEvent { // getter and setter methods from ILoggingEvent omitted int getVersion(); makeImmutable(); } LoggingEvent is intended to be used within the application generating the logging event. LoggingEventMemento is intended for remote applications (applications other than the application at the origin of the event) and for longer term lifespan. LoggingEventMemento objects are intended to be compatible across logback versions. If possible, LoggingEventMemento should also be suitable for long term storage (on disk). Both LoggingEvent and LoggingEventMemento implement the ILoggingEvent interface so that most logback-classic components, assuming they expect to operate on ILoggingEvent instances, will be able to handle LoggingEvent or LoggingEventMemento objects interchangeably. Instead of LoggingEvent, those appenders which perform serialization, will be serializing instances of LoggingEventMemento. The asLoggingEventMemento() method in LoggingEvent will return a LoggingEventMemento image of a given LoggingEvent. Obviously there several technical obstacles to overcome. However, I am soliciting your comments about the general goals of the above redesign. Do they make sense? Have I omitted important goals? TIA, -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch

7 47

[JIRA] Created: (CONSPLUG-18) Incorrect Thread name in Logback plugin console
by Leung Wang Hei (JIRA) 03 Mar '09

03 Mar '09

Incorrect Thread name in Logback plugin console ----------------------------------------------- Key: CONSPLUG-18 URL: http://jira.qos.ch/browse/CONSPLUG-18 Project: Console Plugin Issue Type: Bug Components: other Environment: Win XPP SP2 Eclipse 3.4.0 Build id: I20080617-2000 JVM 1.6.0_12 Reporter: Leung Wang Hei Assignee: Logback dev list I am using the eclipse logback console but found that [%thread] gives me the wrong thread name. It shows something like [Thread-70] rather than the real thread name in my application. Here is the logging statement private static final Logger logger = LoggerFactory.getLogger(TestView.class); .... logger.error("testing test ing"); .... I noticed there is a code in the ch.qos.logback.eclipse.reciever.SocketNode (line 59), which I copied here. try { while (true) { // read an event from the wire event = (LoggingEvent) ois.readObject(); // trick to keep the original thread name event.getThreadName(); // add it to the manager's LoggingEvent list LoggingEventManager.getManager().addLoggingEvent(event); } The comment said it is a trick to keep the original thread name. It seems not working anymore, is it? Or, am I missing something? Thanks a lot -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 0

What is the most efficient way - preferrably platform agnostic - to submit events from "the outside"?
by Thorbjoern Ravn Andersen 03 Mar '09

03 Mar '09

As mentioned in the thread about LoggingEvent refactoring, I think that the underlying problem that should be solved first, is how to transport logging events in and out of a JVM as efficiently as possible. Efficient means at least to me: * Little overhead - both network bandwith wise, and cpu wise * Large amounts of events can be sent fast - the host program is not tied up. * Large amounts of events can be received fast - perhaps a bundle concept? * Supports Unicode (no 8-bit folding) The current approach for the Socketserver is a simple accept-and-fork system where the incoming data is serialized log events. Pro: Data stream is rather compact -> network friendly. Contra: Log events can only originate on a JVM with a compatible version of logback. Jörn, perhaps you'd like to do a more complete writeup on what should be anticipated? Larger datablocks may be acceptible if the data is lightly compressed. My personal preference before actual experiments would be a XML format in a dialect supported by a third party, e.g. XMLDecoder/Encoder or an Apache project, as it is important to delegate the performance work to another team. If we bring ZeroConf into it too for the discovery process it would be nice. The default behaviour of network loggers in Java has not been established yet. -- Thorbjørn Ravn Andersen "...plus... Tubular Bells!"

6 37

protobuf
by Maarten Bosteels 02 Mar '09

02 Mar '09

Hello, My first quick draft of a .proto file [1] for logging events with a quick-and-dirty attempt to create a Logback => ProtoBuf Convertor [2] I am sure it's not perfect. So all comments are welcome. It's probably too logback specific, my goal is that the protocol could also be used for transmitting log4j events. I haven't done any benchmarking yet (and I haven't compiled the proto file optimized for speed) [1] http://code.google.com/p/firewood/source/browse/trunk/compare-formats/src/m… [2] http://code.google.com/p/firewood/source/browse/trunk/compare-formats/src/m… [3] http://code.google.com/p/firewood/source/browse/trunk/compare-formats/src/t… regards, Maarten

1 0

spelling error in ch.qos.logback.core.Context
by Maarten Bosteels 02 Mar '09

02 Mar '09

Hello, getBithTime instead of getBirthTime (missing R) in ch.qos.logback.core.Context and ch.qos.logback.core.ContextBase http://svn.qos.ch/viewvc/logback/trunk/logback-core/src/main/java/ch/qos/lo… regards, Maarten

1 0