[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&lt;LoggingEvent> writerAppender = new WriterAppender&lt;LoggingEvent>();
+    WriterAppender&lt;ILoggingEvent> writerAppender = new WriterAppender&lt;ILoggingEvent>();
     writerAppender.setContext(lc);
-    writerAppender.setLayout(new EchoLayout&lt;&lt;LoggingEvent>());
+    writerAppender.setLayout(new EchoLayout&lt;&lt;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&lt;LoggingEvent> {
+public class CountingConsoleAppender extends AppenderBase&lt;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&lt;LoggingEvent> {
+public class MySampleLayout extends LayoutBase&lt;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&lt;LoggingEvent&gt;</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&lt;ILoggingEvent&gt;</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&lt;LoggingEvent> {
+public class MySampleLayout2 extends LayoutBase&lt;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&lt;LoggingEvent> appender = new ConsoleAppender&lt;LoggingEvent>();
+    ConsoleAppender&lt;ILoggingEvent> appender = new ConsoleAppender&lt;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&lt;LoggingEvent></b> {
+public class TrivialLogbackLayout extends <b>LayoutBase&lt;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&lt;LoggingEvent></code> class.
+   <code>LayoutBase&lt;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&lt;LoggingEvent> {
+public class TrivialLogbackAppender extends AppenderBase&lt;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