[logback-dev] svn commit: r2285 - in logback/trunk: logback-classic/src/main/java/ch/qos/logback/classic/spi logback-site/src/site/pages logback-site/src/site/pages/manual
noreply.ceki at qos.ch
noreply.ceki at qos.ch
Fri Jun 12 23:00:55 CEST 2009
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.
More information about the logback-dev
mailing list