Author: ceki Date: Fri Jun 12 23:00:55 2009 New Revision: 2285 Added: logback/trunk/logback-site/src/site/pages/deadlock.html Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/ILoggingEvent.java logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggingEvent.java logback/trunk/logback-site/src/site/pages/manual/appenders.html logback/trunk/logback-site/src/site/pages/manual/architecture.html logback/trunk/logback-site/src/site/pages/manual/filters.html logback/trunk/logback-site/src/site/pages/manual/layouts.html logback/trunk/logback-site/src/site/pages/manual/mdc.html logback/trunk/logback-site/src/site/pages/manual/migrationFromLog4j.html Log: - updating documentation to refer to ILoggingEvent instead of LoggingEvent where appropriate Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/ILoggingEvent.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/ILoggingEvent.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/ILoggingEvent.java Fri Jun 12 23:00:55 2009 @@ -7,7 +7,8 @@ import ch.qos.logback.classic.Level; /** - * The core interface in logback-classic. + * The central interface in logback-classic. In a nutshell, logback-classic is + * nothing more than a processing chain built around this interface. * * @author Ceki Gülcü * @since 0.9.16 @@ -31,8 +32,8 @@ public IThrowableProxy getThrowableProxy(); /** - * Return caller data associated with this event. Note that calling - * this event may trigger the computation of caller data. + * Return caller data associated with this event. Note that calling this event + * may trigger the computation of caller data. * * @return the caller data associated with this event. * Modified: logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggingEvent.java ============================================================================== --- logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggingEvent.java (original) +++ logback/trunk/logback-classic/src/main/java/ch/qos/logback/classic/spi/LoggingEvent.java Fri Jun 12 23:00:55 2009 @@ -25,10 +25,10 @@ /** * The internal representation of logging events. When an affirmative decision * is made to log then a <code>LoggingEvent</code> instance is created. This - * instance is passed around to the different Logback components. + * instance is passed around to the different logback-classic components. * - * <p> Writers of Logback components such as appenders should be aware of that - * some of the LoggingEvent fields are initialized lazily. Therefore, an + * <p> Writers of logback-classic components such as appenders should be aware + * of that some of the LoggingEvent fields are initialized lazily. Therefore, an * appender wishing to output data to be later correctly read by a receiver, * must initialize "lazy" fields prior to writing them out. See the * {@link #prepareForDeferredProcessing()} method for the exact list. </p> @@ -54,7 +54,7 @@ private String loggerName; private LoggerContext loggerContext; private LoggerContextVO loggerContextVO; - + /** * Level of logging event. * @@ -243,7 +243,8 @@ */ public StackTraceElement[] getCallerData() { if (callerDataArray == null) { - callerDataArray = CallerData.extract(new Throwable(), fqnOfLoggerClass, loggerContext.getMaxCallerDataDepth()); + callerDataArray = CallerData.extract(new Throwable(), fqnOfLoggerClass, + loggerContext.getMaxCallerDataDepth()); } return callerDataArray; } Added: logback/trunk/logback-site/src/site/pages/deadlock.html ============================================================================== --- (empty file) +++ logback/trunk/logback-site/src/site/pages/deadlock.html Fri Jun 12 23:00:55 2009 @@ -0,0 +1,79 @@ + + +logback-core/src/main/java/ch/qos/logback/core/AppenderBase.java: + public synchronized void doAppend(E eventObject) + +logback-core/src/main/java/ch/qos/logback/core/BasicStatusManager.java: + locks: + Object statusListLock + Object statusListenerListLock + exposition: to derived classes + +logback-core/src/main/java/ch/qos/logback/core/status/StatusBase.java: + locks: this + lock exposition: this + +logback-classic/src/main/java/ch/qos/logback/classic/selector/ContextJNDISelector.java: + locks: synchronizedContextMap + lock exposition: none + + +logback-classic/src/main/java/ch/qos/logback/classic/Logger.java + locks: synchronizedContextMap + lock exposition: none + +logback-classic/src/main/java/ch/qos/logback/classic/LoggerContext.java + locks: logger, + loggerCache should be syncronzied but is not + lock exposition: + +logback-classic/src/main/java/ch/qos/logback/classic/Logger.java: + * synchronized on 'this' (Logger) protecting against simultaneous + * only within addAppender which is synchronized <p> 3) all the other methods + public synchronized void setLevel(Level newLevel) { + private synchronized void handleParentLevelChange(int newParentLevelInt) { + // this method MUST be synchronized. See comments on 'aai' field for further + public synchronized void addAppender(Appender<LoggingEvent> newAppender) { + + +logback-core/src/main/java/ch/qos/logback/core/joran/GenericConfigurator.java: + locks: context + lock exposition: none + + + + + * only within addAppender which is synchronized <p> 3) all the other methods + public synchronized void setLevel(Level newLevel) { + private synchronized void handleParentLevelChange(int newParentLevelInt) { + // this method MUST be synchronized. See comments on 'aai' field for further + public synchronized void addAppender(Appender<LoggingEvent> newAppender) { + + + + +logback-core/src/main/java/ch/qos/logback/core/FileAppender.java: public synchronized void openFile(String file_name) throws IOException { + +logback-core/src/main/java/ch/qos/logback/core/net/SMTPAppenderBase.java: synchronized public void stop() { +logback-core/src/main/java/ch/qos/logback/core/net/SocketAppenderBase.java: synchronized (this) { + +logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java: public synchronized void stop() { +logback-core/src/main/java/ch/qos/logback/core/WriterAppender.java: public synchronized void setWriter(Writer writer) { + +logback-classic/src/main/java/ch/qos/logback/classic/net/JMSQueueAppender.java: public synchronized void stop() { +logback-classic/src/main/java/ch/qos/logback/classic/net/JMSQueueAppender.java: // The synchronized modifier avoids concurrent append and close operations +logback-classic/src/main/java/ch/qos/logback/classic/net/JMSTopicAppender.java: public synchronized void stop() { +logback-classic/src/main/java/ch/qos/logback/classic/net/JMSTopicAppender.java: // The synchronized modifier avoids concurrent append and close operations + + +logback-core/src/main/java/ch/qos/logback/core/status/StatusBase.java: public synchronized void add(Status child) { +logback-core/src/main/java/ch/qos/logback/core/status/StatusBase.java: public synchronized boolean hasChildren() { +logback-core/src/main/java/ch/qos/logback/core/status/StatusBase.java: public synchronized Iterator<Status> iterator() { +logback-core/src/main/java/ch/qos/logback/core/status/StatusBase.java: public synchronized boolean remove(Status statusToRemove) { + + +logback-classic/src/main/java/ch/qos/logback/classic/net/SimpleSocketServer.java: synchronized (socketNodeList) { +logback-classic/src/main/java/ch/qos/logback/classic/net/SimpleSocketServer.java: synchronized(this) { +logback-classic/src/main/java/ch/qos/logback/classic/net/SimpleSocketServer.java: synchronized (socketNodeList) { +logback-classic/src/main/java/ch/qos/logback/classic/net/SimpleSocketServer.java: synchronized (socketNodeList) { +logback-classic/src/main/java/ch/qos/logback/classic/pattern/DateConverter.java: // the AppenderBase.doAppend is synchronized, we are should be Modified: logback/trunk/logback-site/src/site/pages/manual/appenders.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/appenders.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/appenders.html Fri Jun 12 23:00:55 2009 @@ -69,7 +69,7 @@ <em>E</em> as its only parameter. The actual type of <em>E</em> would vary depending on the logback module. Within the logback-classic module <em>E</em> would be of type <a - href="../apidocs/ch/qos/logback/classic/spi/LoggingEvent.html">LoggingEvent</a> + href="../apidocs/ch/qos/logback/classic/spi/ILoggingEvent.html">ILoggingEvent</a> and within the logback-access module it would be of type <a href="../apidocs/ch/qos/logback/access/spi/AccessEvent.html">AccessEvent</a>. The <code>doAppend()</code> method is perhaps the most important in @@ -303,6 +303,7 @@ import ch.qos.logback.classic.Logger; import ch.qos.logback.classic.LoggerContext; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.WriterAppender; import ch.qos.logback.core.layout.EchoLayout; @@ -311,9 +312,9 @@ public static void main(String[] args) throws Exception { LoggerContext lc = (LoggerContext) LoggerFactory.getILoggerFactory(); lc.reset(); // we want to override the default-config. - WriterAppender<LoggingEvent> writerAppender = new WriterAppender<LoggingEvent>(); + WriterAppender<ILoggingEvent> writerAppender = new WriterAppender<ILoggingEvent>(); writerAppender.setContext(lc); - writerAppender.setLayout(new EchoLayout<<LoggingEvent>()); + writerAppender.setLayout(new EchoLayout<<ILoggingEvent>()); OutputStream os = new FileOutputStream("exitWoes1.log"); writerAppender.setWriter(new OutputStreamWriter(os)); @@ -1254,7 +1255,9 @@ <p>While logging events are generic in logback-core, within logback-classic they are always instances of - <code>LoggingEvent</code>. + <code>ILoggingEvent</code>. Logback-classic is nothing more than a + specialized processing pipleline handling instances of + <code>ILoggingEvent</code>. </p> @@ -1266,8 +1269,12 @@ resources. In contrast, the <a href="../xref/ch/qos/logback/classic/net/SocketAppender.html"> <code>SocketAppender</code></a> is designed to log to a remote - entity by transmitting serialized <code>LoggingEvent</code> - objects over the wire. Remote logging is non-intrusive as far as + entity by transmitting serialized <code>ILoggingEvent</code> + instances over the wire. The actual type of the serialized event + is <a + href="../xref/ch/qos/logback/classic/spi/LoggingEventVO.html"><code>LoggingEventVO</code></a> + which implements the <code>ILoggingEvent</code> + interface. Nevertheless, remote logging is non-intrusive as far as the logging event is concerned. On the receiving end after de-serialization, the event can be logged as if it were generated locally. Multiple <code>SocketAppender</code> instances running of @@ -1732,37 +1739,41 @@ <h4>Comments on JMS appenders</h4> - <p> - Transmitting a packet of information using JMS is certain to be substantially - slower then sending the same packet using raw TCP sockets. JMS vendors bragging - about the performance of their messaging platform tend to omit this simple fact. - Guaranteed store and forward messaging comes at a hefty price. - In return for increased cost, JMS messaging provides decoupling of - sender and receiver. As long as the JMS provider is reachable, messages - will eventually arrive at destination. - However, what if the JMS server is down or simply unreachable? - </p> - - <p> - According to the JMS specification, producers can mark a message as either - persistent or non-persistent. The persistent delivery mode instructs the JMS provider - to log the message to stable storage as part of the client's send operation, allowing - the message to survive provider crashes. JMS appenders do not set the delivery - mode of messages it produces because according to the JMS specification, - the delivery mode is considered as an administered property. - </p> - - <p> - Once a message reaches the JMS provider, the provider assumes the responsibility - of delivering it to its destination, relieving the client from this chore. - What if the JMS server is unreachable? The JMS API provides an - <code>ExceptionListener</code> interface to deal with this situation. - When the client runtime of the JMS provider detects a lost connection to the JMS server, - it calls the <code>onException()</code> method of the registered - <code>ExceptionListener</code>. Once notified of the problem, client code can attempt - to reestablish the connection. According to the section 4.3.8 of the JMS specification, - the provider should attempt to resolve connection problems prior to notifying the client. - The JMS appenders do not implement the <code>ExceptionListener</code> interface. + <p>Transmitting a packet of information using JMS is certain to be + substantially slower then sending the same packet using raw TCP + sockets. JMS vendors bragging about the performance of their + messaging platform tend to omit this simple fact. Guaranteed + store and forward messaging comes at a hefty price. In return for + increased cost, JMS messaging provides decoupling of sender and + receiver. As long as the JMS provider is reachable, messages will + eventually arrive at destination. However, what if the JMS server + is down or simply unreachable? + </p> + + <p>According to the JMS specification, producers can mark a + message as either persistent or non-persistent. The persistent + delivery mode instructs the JMS provider to log the message to + stable storage as part of the client's send operation, allowing + the message to survive provider crashes. JMS appenders do not set + the delivery mode of messages it produces because according to the + JMS specification, the delivery mode is considered as an + administered property. + </p> + + <p>Once a message reaches the JMS provider, the provider assumes + the responsibility of delivering it to its destination, relieving + the client from this chore. What if the JMS server is + unreachable? The JMS API provides an + <code>ExceptionListener</code> interface to deal with this + situation. When the client runtime of the JMS provider detects a + lost connection to the JMS server, it calls the + <code>onException()</code> method of the registered + <code>ExceptionListener</code>. Once notified of the problem, + client code can attempt to reestablish the connection. According + to the section 4.3.8 of the JMS specification, the provider should + attempt to resolve connection problems prior to notifying the + client. The JMS appenders do not implement the + <code>ExceptionListener</code> interface. </p> <a name="JMSTopicAppender"></a> @@ -1778,14 +1789,14 @@ Its most important method, <code>doAppend()</code> is listed below: </p> -<div class="source"><pre>public void append(LoggingEvent event) { +<div class="source"><pre>public void append(ILoggingEvent event) { if (!isStarted()) { return; } try { ObjectMessage msg = topicSession.createObjectMessage(); - + Serializable so = pst.transform(event); msg.setObject(event); topicPublisher.publish(msg); successiveFailureCount = 0; @@ -1799,19 +1810,23 @@ }</pre></div> <p> - The <code>isStarted()</code> method allows the appender to check whether - prerequisite conditions for its proper functioning, in particular the - availability of a valid and open <code>TopicConnection</code> and a - <code>TopicSession</code>, are fulfilled. If that is not the case, - the append method returns without performing any work. - If the prerequisite conditions are fulfilled, then the method - proceeds to publish the logging event. This is done by obtaining a - <code>javax.jms.ObjectMessage</code> from the <code>TopicSession</code> - and then setting its payload to the logging event received as - the input parameter. Once the payload of the message is set, it is - published. The fact that <code>LoggingEvent</code> is serializable - has its importance, as only Serializable objects can be - transported within an <code>ObjectMessage</code>. + The <code>isStarted()</code> method allows the appender to check + whether prerequisite conditions for its proper functioning, in + particular the availability of a valid and open + <code>TopicConnection</code> and a <code>TopicSession</code>, + are fulfilled. If that is not the case, the append method + returns without performing any work. If the prerequisite + conditions are fulfilled, then the method proceeds to publish + the logging event. This is done by obtaining a + <code>javax.jms.ObjectMessage</code> from the + <code>TopicSession</code> and then setting its payload to the + logging event received as the input parameter. Once the payload + of the message is set, it is published. Note that the + <code>ILoggingEvent</code> is transfomed to a serializable + object by a <a + href="../xref/ch/qos/logback/core/spi/PreSerializationTransformer.html">PreSerializationTransformer</a>. Only + Serializable objects can be transported within an + <code>ObjectMessage</code>. </p> <p> @@ -1828,12 +1843,12 @@ </p> <div class="source"><pre>public void onMessage(javax.jms.Message message) { - LoggingEvent event; + ILoggingEvent event; try { if (message instanceof ObjectMessage) { ObjectMessage objectMessage = (ObjectMessage) message; - event = (LoggingEvent) objectMessage.getObject(); - Logger log = (Logger) LoggerFactory.getLogger(event.getLoggerRemoteView().getName()); + event = (ILoggingEvent) objectMessage.getObject(); + Logger log = (Logger) LoggerFactory.getLogger(event.getLoggerName()); log.callAppenders(event); } else { logger.warn("Received message is of type " + message.getJMSType() @@ -3216,26 +3231,30 @@ href="#WriteYourOwnAppender">Writing your own Appender</a></h3> - <p>You can easily write your appender by sub-classing <code>AppenderBase</code>. - It handles support for filters, status among other functionality shared by most appenders. - The derived class only needs to implement one method, namely + <p>You can easily write your appender by sub-classing + <code>AppenderBase</code>. It handles support for filters, status + among other functionality shared by most appenders. The derived + class only needs to implement one method, namely <code>append(Object eventObject)</code>. </p> - <p>The <code>CountingConsoleAppender</code>, which we list next, appends a limited - number of incoming events on the console. It shuts down after the limit is reached. - It uses a <code>Layout</code> to format the events and accepts a parameter, + <p>The <code>CountingConsoleAppender</code>, which we list next, + appends a limited number of incoming events on the console. It + shuts down after the limit is reached. It uses a + <code>Layout</code> to format the events and accepts a parameter, thus a few more methods are needed. </p> - <em>Example 4.<span class="autoExec"/>: <code>CountingConsoleAppender</code> (logback-examples/src/main/java/chapter4/CountingConsoleAppender.java)</em> + <em>Example 4.<span class="autoExec"/>: + <code>CountingConsoleAppender</code> + (logback-examples/src/main/java/chapter4/CountingConsoleAppender.java)</em> <p class="source">package chapter4; import ch.qos.logback.core.AppenderBase; import ch.qos.logback.core.Layout; -public class CountingConsoleAppender extends AppenderBase<LoggingEvent> { +public class CountingConsoleAppender extends AppenderBase<ILoggingEvent> { static int DEFAULT_LIMIT = 16; int counter = 0; int limit = DEFAULT_LIMIT; @@ -3261,7 +3280,7 @@ super.start(); } - public void append(LoggingEvent event) { + public void append(ILoggingEvent event) { if (counter >= limit) { return; Modified: logback/trunk/logback-site/src/site/pages/manual/architecture.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/architecture.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/architecture.html Fri Jun 12 23:00:55 2009 @@ -762,14 +762,14 @@ <h4>3. Create a <code>LoggingEvent</code> object</h4> - <p>If the request passed the previous filters, logback will create a - <code>ch.qos.logback.classic.LoggingEvent</code> object containing - all the relevant parameters of the request, such as the logger of - the request, the request level, the message itself, the exception - that might have been passed along with the request, the current - time, the current thread, various data about the class that issued - the logging request and the <code>MDC</code>. Note that some of - these fields are initialized lazily, that is only when they are + <p>If the request survivedy the previous filters, logback will + create a <code>ch.qos.logback.classic.LoggingEvent</code> object + containing all the relevant parameters of the request, such as the + logger of the request, the request level, the message itself, the + exception that might have been passed along with the request, the + current time, the current thread, various data about the class that + issued the logging request and the <code>MDC</code>. Note that some + of these fields are initialized lazily, that is only when they are actually needed. The <code>MDC</code> is used to decorate the logging request with additional contextual information. MDC is discussed in a <a href="mdc.html">subsequent chapter</a>.</p> @@ -777,11 +777,11 @@ <h4>4. Invoking appenders</h4> <p>After the creation of a <code>LoggingEvent</code> object, logback - invokes the <code>doAppend()</code> methods of all the applicable - appenders, that is, the appenders inherited from the logger context. + will invoke the <code>doAppend()</code> methods of all the + applicable appenders, that is, the appenders inherited from the + logger context. </p> - <p>All appenders shipped with the logback distribution extend the <code>AppenderBase</code> abstract class that implements the <code>doAppend</code> method in a synchronized block ensuring Modified: logback/trunk/logback-site/src/site/pages/manual/filters.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/filters.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/filters.html Fri Jun 12 23:00:55 2009 @@ -61,7 +61,7 @@ <p><code>Filter</code> objects all extend the <a href="../xref/ch/qos/logback/core/filter/Filter.html"><code>Filter</code></a> abstract class. The <code>decide(Object event)</code> method is - passed a newly created <code>LoggingEvent</code> object. + passed a newly created <code>ILoggingEvent</code> instance. </p> <h3>Filter chains</h3> Modified: logback/trunk/logback-site/src/site/pages/manual/layouts.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/layouts.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/layouts.html Fri Jun 12 23:00:55 2009 @@ -66,8 +66,8 @@ <h2>Logback-classic</h2> <p>Logback-classic is wired to processes only events of type - <a href="../xref/ch/qos/logback/classic/spi/LoggingEvent.html"> - <code>ch.qos.logback.classic.spi.LoggingEvent</code></a>. This + <a href="../xref/ch/qos/logback/classic/spi/ILoggingEvent.html"> + <code>ch.qos.logback.classic.spi.ILoggingEvent</code></a>. This fact will apparent for the remaining of this section. </p> @@ -92,59 +92,51 @@ <div class="source"><pre>package chapter5; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.LayoutBase; -public class MySampleLayout extends LayoutBase<LoggingEvent> { +public class MySampleLayout extends LayoutBase<ILoggingEvent> { - public String doLayout(LoggingEvent event) { + public String doLayout(ILoggingEvent event) { StringBuffer sbuf = new StringBuffer(128); - sbuf.append(event.getTimeStamp() - LoggingEvent.getStartTime()); + sbuf.append(event.getTimeStamp() - event.getLoggingContextVO.getBirthTime()); sbuf.append(" "); sbuf.append(event.getLevel()); sbuf.append(" ["); sbuf.append(event.getThreadName()); sbuf.append("] "); - sbuf.append(event.getLoggerRemoteView().getName()); + sbuf.append(event.getLoggerName(); sbuf.append(" - "); sbuf.append(event.getFormattedMessage()); - sbuf.append(LINE_SEP); + sbuf.append(CoreConstants.LINE_SEP); return sbuf.toString(); } }</pre></div> - <p> - Note that <code>MySampleLayout</code> extends <a - href="../xref/ch/qos/logback/core/LayoutBase.html"> - <code>LayoutBase</code></a>. This class manages state shared by - all <code>Layout</code> classes, such as whether the layout is - started or stopped, header, footer and content type data. It - allows the developer to concentrate on the formatting she - expects from her <code>Layout</code>. Note that the - <code>LayoutBase</code> class is generic. In its class - declaration, <code>MySampleLayout</code> extends a typed - <code>LayoutBase</code>, - <code>LayoutBase<LoggingEvent></code>, instead of generic - one. + <p>Note that <code>MySampleLayout</code> extends <a + href="../xref/ch/qos/logback/core/LayoutBase.html"> + <code>LayoutBase</code></a>. This class manages state shared by + all <code>Layout</code> classes, such as whether the layout is + started or stopped, header, footer and content type data. It + allows the developer to concentrate on the formatting expected + from his/her <code>Layout</code>. Note that the + <code>LayoutBase</code> class is generic. In its class + declaration, <code>MySampleLayout</code> extends + <code>LayoutBase<ILoggingEvent></code>. </p> - <p>The <code>doLayout(LoggingEvent event)</code> method, i.e. the + <p>The <code>doLayout(ILoggingEvent event)</code> method, i.e. the only method in <code>MySampleLayout</code>, begins by instantiating a <code>StringBuffer</code>. It proceeds by adding various fields of the event parameter. The Texan from Texas was careful to print the formatted form of the message. This is - important when there are one or more parameters passed along with + significant in case one or more parameters were passed along with the logging request. </p> - <p>In the above listing of the <code>Layout</code> class, the - <code>LINE_SEP</code> field is inherited from the - <code>Layout</code> interface. It refers to the value returned by - <code>System.getProperty("line.separator")</code> method, that is - system dependent line separator character(s). After adding these - system dependent character(s), the <code>doLayout()</code> method - converts <code>sbuf</code> to <code>String</code> and returns the - resulting value. + <p>After adding these various characters to the string buffer, the + <code>doLayout()</code> method converts the buffer into + <code>String</code> and returns the resulting value. </p> <p>In the above example, the <code>doLayout</code> method ignores @@ -211,10 +203,10 @@ <p class="source">package chapter5; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.LayoutBase; -public class MySampleLayout2 extends LayoutBase<LoggingEvent> { +public class MySampleLayout2 extends LayoutBase<ILoggingEvent> { String prefix = null; boolean printThreadName = true; @@ -227,12 +219,12 @@ this.printThreadName = printThreadName; }</b> - public String doLayout(LoggingEvent event) { + public String doLayout(ILoggingEvent event) { StringBuffer sbuf = new StringBuffer(128); <b>if (prefix != null) { sbuf.append(prefix + ": "); }</b> - sbuf.append(event.getTimeStamp() - LoggingEvent.getStartTime()); + sbuf.append(event.getTimeStamp() - event.getLoggerContextVO().getBirthTime()); sbuf.append(" "); sbuf.append(event.getLevel()); <b>if (printThreadName) { @@ -242,7 +234,7 @@ } else { sbuf.append(" "); }</b> - sbuf.append(event.getLoggerRemoteView().getName()); + sbuf.append(event.getLoggerName()); sbuf.append(" - "); sbuf.append(event.getFormattedMessage()); sbuf.append(LINE_SEP); @@ -327,7 +319,7 @@ <b>layout.setPattern("%-5level [%thread]: %message%n");</b> <b>layout.start();</b> - ConsoleAppender<LoggingEvent> appender = new ConsoleAppender<LoggingEvent>(); + ConsoleAppender<ILoggingEvent> appender = new ConsoleAppender<ILoggingEvent>(); appender.setContext(rootLogger.getLoggerContext()); appender.setLayout(layout); appender.start(); @@ -1379,19 +1371,20 @@ <p>Building a custom conversion specifier consists of two steps. </p> - <p>First, you must sub-class the <code>Converter</code> class. <a - href="../xref/ch/qos/logback/core/pattern/Converter.html"> - <code>Converter</code></a> objects are responsible for extracting - information out of <code>LoggingEvent</code> objects and returning - it as String. For example, the + <p>First, you must extend the <code>ClassicConverter</code> + class. <a + href="../xref/ch/qos/logback/classic/pattern/ClassicConverter.html"> + <code>ClassicConverter</code></a> objects are responsible for + extracting information out of <code>ILoggingEvent</code> instances + and producing a String. For example, the <a href="../xref/ch/qos/logback/classic/pattern/LoggerConverter.html"> <code>LoggerConverter</code></a>, the converter underlying the - %logger conversion word, extracts the name of the logger from the - <code>LoggingEvent</code> and returns it as a String. It might + %logger conversion word, extracts the name of the logger from + <code>ILoggingEvent</code> and returns it as a String. It might abbreviate the logger name in the process.</p> - <p>Let us say that our customized <code>Converter</code> colors - the level of the logging event, according to ANSI terminal + <p>Let us say that our customized <code>ClassicConverter</code> + colors the level of the logging event, according to ANSI terminal conventions. Here is a possible implementation:</p> <em> Example 5.4: Sample Converter Example @@ -1401,7 +1394,7 @@ import ch.qos.logback.classic.Level; import ch.qos.logback.classic.pattern.ClassicConverter; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; public class MySampleConverter extends ClassicConverter { @@ -1411,7 +1404,7 @@ private static final String WARN_COLOR = "\u001b[0;33m"; @Override - <b>public String convert(LoggingEvent event) { + <b>public String convert(ILoggingEvent event) { StringBuffer sbuf = new StringBuffer(); sbuf.append(getColor(event.getLevel())); sbuf.append(event.getLevel()); Modified: logback/trunk/logback-site/src/site/pages/manual/mdc.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/mdc.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/mdc.html Fri Jun 12 23:00:55 2009 @@ -107,7 +107,6 @@ import org.slf4j.MDC; import ch.qos.logback.classic.PatternLayout; -import ch.qos.logback.classic.spi.LoggingEvent; import ch.qos.logback.core.ConsoleAppender; public class SimpleMDC { Modified: logback/trunk/logback-site/src/site/pages/manual/migrationFromLog4j.html ============================================================================== --- logback/trunk/logback-site/src/site/pages/manual/migrationFromLog4j.html (original) +++ logback/trunk/logback-site/src/site/pages/manual/migrationFromLog4j.html Fri Jun 12 23:00:55 2009 @@ -42,15 +42,16 @@ and layouts exist in both frameworks and serve identical purposes. Similarly, the most important internal data-structure, namely <code>LoggingEvent</code> exists in both frameworks with - rather similar but non-identical implementations. Most of the - changes requried in migrating log4j components to logback-classic - are related to differences in implementation of the - <code>LoggingEvent</code> class. Rest assured, these differences - are rather limited. If in spite of your best efforts you are - unable to migrate any given log4j component to logback-classic, do - post a question on the <a href="../mailinglist.html">logback-dev - mailing list</a>. A logback developper should be able to provide - guidance. + rather similar but non-identical implementations. Most notably, In + logback-classic <code>LoggingEvent</code> implements the + <code>ILoggingEvent</code> interface. Most of the changes requried + in migrating log4j components to logback-classic are related to + differences in implementation of the <code>LoggingEvent</code> + class. Rest assured, these differences are rather limited. If in + spite of your best efforts you are unable to migrate any given + log4j component to logback-classic, do post a question on the <a + href="../mailinglist.html">logback-dev mailing list</a>. A logback + developper should be able to provide guidance. </p> @@ -90,12 +91,12 @@ <p class="source">package chapter11; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.LayoutBase; -public class TrivialLogbackLayout extends <b>LayoutBase<LoggingEvent></b> { +public class TrivialLogbackLayout extends <b>LayoutBase<ILoggingEvent></b> { - public String <b>doLayout</b>(LoggingEvent loggingEvent) { + public String <b>doLayout</b>(ILoggingEvent loggingEvent) { return loggingEvent.getMessage(); } } </p> @@ -105,7 +106,7 @@ <code>format</code>() in log4j. The <code>ignoresThrowable</code>() method is not needed and has no equivalent in logback-classic. Note that a logback-classic layout must extend the - <code>LayoutBase<LoggingEvent></code> class. + <code>LayoutBase<ILoggingEvent></code> class. </p> <p>The <code>activateOptions</code>() method merits further @@ -161,10 +162,10 @@ <p class="source">package chapter11; -import ch.qos.logback.classic.spi.LoggingEvent; +import ch.qos.logback.classic.spi.ILoggingEvent; import ch.qos.logback.core.AppenderBase; -public class TrivialLogbackAppender extends AppenderBase<LoggingEvent> { +public class TrivialLogbackAppender extends AppenderBase<ILoggingEvent> { @Override public void start() { @@ -176,7 +177,7 @@ } @Override - protected void append(LoggingEvent loggingevent) { + protected void append(ILoggingEvent loggingevent) { // note that AppenderBase.doAppend will invoke this method only if // this appender was successfully started.