<HTML xmlns="http://www.w3.org/TR/REC-html40" xmlns:a="urn:schemas-microsoft-com:office:access" xmlns:b="urn:schemas-microsoft-com:office:publisher" xmlns:c="urn:schemas-microsoft-com:office:component:spreadsheet" xmlns:D="DAV:" xmlns:dir="http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsp="http://schemas.microsoft.com/sharepoint/dsp" xmlns:dssi="http://schemas.microsoft.com/office/2006/digsig" xmlns:dsss="http://schemas.microsoft.com/office/2006/digsig-setup" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:ec="http://www.w3.org/2001/04/xmlenc#" xmlns:ex12m="http://schemas.microsoft.com/exchange/services/2006/messages" xmlns:ex12t="http://schemas.microsoft.com/exchange/services/2006/types" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns:mdssi="http://schemas.openxmlformats.org/package/2006/digital-signature" xmlns:mrels="http://schemas.openxmlformats.org/package/2006/relationships" xmlns:mver="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:oa="urn:schemas-microsoft-com:office:activation" xmlns:odc="urn:schemas-microsoft-com:office:odc" xmlns:ois="http://schemas.microsoft.com/sharepoint/soap/ois/" xmlns:p="urn:schemas-microsoft-com:office:powerpoint" xmlns:pptsl="http://schemas.microsoft.com/sharepoint/soap/SlideLibrary/" xmlns:q="http://schemas.xmlsoap.org/soap/envelope/" xmlns:rs="urn:schemas-microsoft-com:rowset" xmlns:s="uuid:BDC6E3F0-6DA3-11d1-A2A3-00AA00C14882" xmlns:sp="http://schemas.microsoft.com/sharepoint/" xmlns:sps="http://schemas.microsoft.com/sharepoint/soap/" xmlns:spsl="http://microsoft.com/webservices/SharePointPortalServer/PublishedLinksService" xmlns:spwp="http://microsoft.com/sharepoint/webpartpages" xmlns:ss="urn:schemas-microsoft-com:office:spreadsheet" xmlns:st="&#1;" xmlns:sub="http://schemas.microsoft.com/sharepoint/soap/2002/1/alerts/" xmlns:udc="http://schemas.microsoft.com/data/udc" xmlns:udcp2p="http://schemas.microsoft.com/data/udc/parttopart" xmlns:udcs="http://schemas.microsoft.com/data/udc/soap" xmlns:udcxf="http://schemas.microsoft.com/data/udc/xmlfile" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:wf="http://schemas.microsoft.com/sharepoint/soap/workflow/" xmlns:x="urn:schemas-microsoft-com:office:excel" xmlns:x2="http://schemas.microsoft.com/office/excel/2003/xml" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:Z="urn:schemas-microsoft-com:"><head><META content="text/html; charset=utf-8" http-equiv="Content-Type">

<meta content="text/html; charset=utf-8" http-equiv=Content-Type>
<meta content="Microsoft Word 12 (filtered medium)" name=Generator>
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Tahoma;
        panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:purple;
        text-decoration:underline;}
code
        {mso-style-priority:99;
        font-family:"Courier New";}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
.MsoChpDefault
        {mso-style-type:export-only;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head><BODY>
<DIV>

<div class=Section1>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>Hi,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'><o:p>&nbsp;</o:p></span></p>

<pre><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>I agree with Maarten, if the r.lock() call would be outside the try block than the original exception would be propagated. Having a look at the </span><code>RWDictionary </code><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>example in the javadocs of ReentrantReadWriteLock(http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantReadWriteLock.html), they have the call to the lock() method outside of the try block.</span><o:p></o:p></pre>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p>&nbsp;</o:p></span></p>

<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'>Regards,<o:p></o:p></span></p>

<p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif";
color:black'>Zoltan Szel<br>
</span><b><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Morgan Stanley | IDEAS Practice Areas<br>
</span></b><span style='font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3978<br>
<a href="mailto:Zoli.Szel@MorganStanley.com">Zoli.Szel@MorganStanley.com</a></span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p>

<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'>

<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>
logback-dev-bounces@qos.ch [mailto:logback-dev-bounces@qos.ch] <b>On Behalf Of </b>Maarten
Bosteels<br>
<b>Sent:</b> Tuesday, February 03, 2009 2:34 PM<br>
<b>To:</b> logback developers list<br>
<b>Subject:</b> Re: [logback-dev] IllegalMonitorStateException
inAppenderAttachableImpl.appendLoopOnAppenders()<o:p></o:p></span></p>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

<p class=MsoNormal>Hello,<br>
<br>
I think moving r.lock(); outside of the try block WILL help, because the
original exception will no longer be hidden.<br>
<br>
&gt; Looking at this exception and related code in AppenderAttachableImpl,<br>
&gt; moving the r.lock(); statement outside of the try block will not<br>
&gt; change anything because I believe that r.lock() does not throw<br>
&gt; exceptions. However, looking at ReentrantReadWriteLock.<o:p></o:p></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>ReadLock class'<br>
&gt; lock() method, one is directed to the ReentrantReadWriteLock.Sync<br>
&gt; class and its acquireShared() method. If this method fails to acquire<br>
&gt; the lock due to a RuntimeException, then the subsequent r.unlock()<br>
&gt; call will fail with an IllegalMonitorStateException.<br>
<br>
but if I understand correctly there will be no subsequent call to r.unlock in
this case ??<o:p></o:p></p>

<pre>&nbsp;&nbsp;<strong><span style='font-family:"Courier New"'>public</span></strong> <strong><span style='font-family:"Courier New"'>int</span></strong> appendLoopOnAppenders(E e) {<br>
<br>
<o:p></o:p></pre><pre><a name=56></a>&nbsp;&nbsp;&nbsp; <strong><span style='font-family:"Courier New"'>int</span></strong> size = 0;<br>
<a name=58></a>&nbsp;&nbsp;&nbsp; r.lock();<br>
<br>
<o:p></o:p></pre><pre><a name=57></a>&nbsp;&nbsp;&nbsp; <strong><span style='font-family:"Courier New"'>try</span></strong> {<br>
<a name=59></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <strong><span style='font-family:"Courier New"'>for</span></strong> (Appender&lt;E&gt; appender : appenderList) {<br>
<br>
<o:p></o:p></pre><pre><a name=60></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; appender.doAppend(e);<br>
<a name=61></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; size++;<br>
<br>
<o:p></o:p></pre><pre><a name=62></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>
<a name=63></a>&nbsp;&nbsp;&nbsp; } <strong><span style='font-family:"Courier New"'>finally</span></strong> {<br>
<br>
<o:p></o:p></pre><pre><a name=64></a>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; r.unlock();<br>
<a name=65></a>&nbsp;&nbsp;&nbsp; }<br>
<br>
<o:p></o:p></pre><pre><a name=66></a>&nbsp;&nbsp;&nbsp; <strong><span style='font-family:"Courier New"'>return</span></strong> size;<br>
<a name=67></a>&nbsp; }<br>
<br>
<o:p></o:p></pre><pre><br>
Noiw, when r.lock() throws a RuntimeException, this one will be propagated to the caller, and we don't reach r.unlock(), right ?<br>
<br>
Maarten<o:p></o:p></pre>

<p class=MsoNormal><br>
<br>
&nbsp;In any case,<br>
&gt; r.lock() will not throw an exception since the exception is absorbed<br>
&gt; by the sync.acquireShared method.<o:p></o:p></p>

</div>

<p class=MsoNormal style='margin-bottom:12.0pt'><br>
<br>
<br>
<o:p></o:p></p>

<div>

<p class=MsoNormal>On Tue, Feb 3, 2009 at 12:43 PM, Szel, Zoltan (IDEAS) &lt;<a href="mailto:Zoli.Szel@morganstanley.com">Zoli.Szel@morganstanley.com</a>&gt;
wrote:<o:p></o:p></p>

<p class=MsoNormal>Hi,<br>
<br>
Unfortunately not, we cannot reproduce it but we have the strong feeling this
is about out of memory as you mentioned.<br>
<br>
Regards,<br>
Zoltan Szel<br>
Morgan Stanley | IDEAS Practice Areas<o:p></o:p></p>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>Lechner Odon fasor 8 | Floor 07<br>
Budapest, 1095<br>
Phone: +36 1 881-3978<br>
Zoli.Szel@MorganStanley.com<o:p></o:p></p>

</div>

<div>

<div>

<p class=MsoNormal style='margin-bottom:12.0pt'>-----Original Message-----<br>
From: Ceki Gulcu [mailto:<a href="mailto:ceki@qos.ch">ceki@qos.ch</a>]<br>
Sent: Monday, February 02, 2009 11:17 PM<br>
To: logback developers list<br>
Subject: Re: [logback-dev] IllegalMonitorStateException in
AppenderAttachableImpl.appendLoopOnAppenders()<br>
<br>
<br>
Any luck reproducing this issue?<br>
<br>
Ceki Gulcu wrote:<br>
&gt; Hello Zoltan,<br>
&gt;<br>
&gt; Looking at this exception and related code in AppenderAttachableImpl,<br>
&gt; moving the r.lock(); statement outside of the try block will not<br>
&gt; change anything because I believe that r.lock() does not throw<br>
&gt; exceptions. However, looking at ReentrantReadWriteLock.ReadLock class'<br>
&gt; lock() method, one is directed to the ReentrantReadWriteLock.Sync<br>
&gt; class and its acquireShared() method. If this method fails to acquire<br>
&gt; the lock due to a RuntimeException, then the subsequent r.unlock()<br>
&gt; call will fail with an IllegalMonitorStateException. In any case,<br>
&gt; r.lock() will not throw an exception since the exception is absorbed<br>
&gt; by the sync.acquireShared method.<br>
&gt;<br>
&gt; It would be quite helpful if you were able to reproduce the problem.<br>
&gt;<br>
&gt; We could place the r.unlock() invocation within a try/catch block<br>
&gt; (absorbing the IllegalMonitorStateException you got). However, this is<br>
&gt; may only obfuscate the real cause of the problem, that is an<br>
&gt; OutOfMemoryException or such. We could also imagine that there is a<br>
&gt; bug in ReentrantReadWriteLock. Given its complexity, it's not such an<br>
&gt; outlandish hypothesis.<br>
&gt;<br>
&gt; Otherwise, the only remaining possibility is a bug in logback. But we<br>
&gt; all know that is impossible.<br>
&gt;<br>
&gt; More seriously, I think this bug will be hard to nail down.<br>
&gt;<br>
&gt; Szel, Zoltan (IDEAS) wrote:<br>
&gt;&gt; Hi,<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; We have hit the exception mentioned in the subject in one of our<br>
&gt;&gt; applications. We are using JDK 6 and Logback 0.9.14. &nbsp;Here is the<br>
&gt;&gt; stacktrace:<br>
&gt;&gt;<br>
&gt;&gt; Caused by: java.lang.IllegalMonitorStateException<br>
&gt;&gt; &nbsp;at<br>
&gt;&gt;
java.util.concurrent.locks.ReentrantReadWriteLock$Sync.tryReleaseShared(ReentrantReadWriteLock.java:363)<br>
&gt;&gt;<br>
&gt;&gt; &nbsp;at<br>
&gt;&gt; java.util.concurrent.locks.AbstractQueuedSynchronizer.releaseShared(AbstractQueuedSynchronizer.java:1253)<br>
&gt;&gt;<br>
&gt;&gt; &nbsp;at<br>
&gt;&gt;
java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.unlock(ReentrantReadWriteLock.java:745)<br>
&gt;&gt;<br>
&gt;&gt; &nbsp;at<br>
&gt;&gt;
ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:64)<br>
&gt;&gt;<br>
&gt;&gt; &nbsp;at
ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)<br>
&gt;&gt; &nbsp;at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)<br>
&gt;&gt; &nbsp;at<br>
&gt;&gt;
ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:439)<br>
&gt;&gt; &nbsp;at ch.qos.logback.classic.Logger.filterAndLog_1(Logger.java:411)<br>
&gt;&gt; &nbsp;at ch.qos.logback.classic.Logger.debug(Logger.java:504)<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; I have checked the code and it seems to me this can only happen if the<br>
&gt;&gt; readLock.lock() method throws an exception:<br>
&gt;&gt;<br>
&gt;&gt; *public* *int* appendLoopOnAppenders(E e) {<br>
&gt;&gt;<br>
&gt;&gt; 56<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#56" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#56</a>&gt;<br>
&gt;&gt; *int* size = 0;<br>
&gt;&gt;<br>
&gt;&gt; 57<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#57" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#57</a>&gt;<br>
&gt;&gt; *try* {<br>
&gt;&gt;<br>
&gt;&gt; 58<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#58" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#58</a>&gt;<br>
&gt;&gt; r.lock();<br>
&gt;&gt;<br>
&gt;&gt; 59<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#59" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#59</a>&gt;<br>
&gt;&gt; *for* (Appender&lt;E&gt; appender : appenderList) {<br>
&gt;&gt;<br>
&gt;&gt; 60<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#60" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#60</a>&gt;<br>
&gt;&gt; appender.doAppend(e);<br>
&gt;&gt;<br>
&gt;&gt; 61<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#61" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#61</a>&gt;<br>
&gt;&gt; size++;<br>
&gt;&gt;<br>
&gt;&gt; 62<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#62" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#62</a>&gt;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; 63<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#63" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#63</a>&gt;<br>
&gt;&gt; } *finally* {<br>
&gt;&gt;<br>
&gt;&gt; 64<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#64" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#64</a>&gt;<br>
&gt;&gt; r.unlock();<br>
&gt;&gt;<br>
&gt;&gt; 65<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#65" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#65</a>&gt;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; 66<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#66" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#66</a>&gt;<br>
&gt;&gt; *return* size;<br>
&gt;&gt;<br>
&gt;&gt; 67<br>
&gt;&gt; &lt;<a href="http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#67" target="_blank">http://logback.qos.ch/xref/ch/qos/logback/core/spi/AppenderAttachableImpl.html#67</a>&gt;<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; if r.lock() in line 58 throws an exception for some reason than in the<br>
&gt;&gt; finally block the unlock will throw also an exception which will hide<br>
&gt;&gt; the original one. I cannot see any other reason why the unlock would<br>
&gt;&gt; throw this exception in this scenario. I am not yet able to reproduce<br>
&gt;&gt; it, but I thought this exception worth a mail. The only suggestion I<br>
&gt;&gt; have for now is to move the r.lock() call out of the try block,<br>
&gt;&gt; because if that is the bad guy, than we would have the original<br>
&gt;&gt; exception propagated.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; If I have more information on this issue I will update this thread.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Regards,<br>
&gt;&gt;<br>
&gt;&gt; Zoltan Szel<br>
&gt;&gt; *Morgan Stanley | IDEAS PRACTICE AREAS<br>
&gt;&gt; *Lechner Odon fasor 8 | Floor 07<br>
&gt;&gt; Budapest, 1095<br>
&gt;&gt; Phone: +36 1 881-3978<br>
&gt;&gt; Zoli.Szel@MorganStanley.com &lt;mailto:<a href="mailto:Zoli.Szel@MorganStanley.com">Zoli.Szel@MorganStanley.com</a>&gt;<br>
&gt;&gt;<br>
&gt;&gt;
------------------------------------------------------------------------<br>
&gt;&gt;<br>
&gt;&gt; NOTICE: If received in error, please destroy and notify sender. Sender<br>
&gt;&gt; does not intend to waive confidentiality or privilege. Use of this<br>
&gt;&gt; email is prohibited when received in error.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;
------------------------------------------------------------------------<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; logback-dev mailing list<br>
&gt;&gt; logback-dev@qos.ch<br>
&gt;&gt; <a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank">http://qos.ch/mailman/listinfo/logback-dev</a><br>
&gt;<br>
<br>
--<br>
Ceki Gülcü<br>
Logback: The reliable, generic, fast and flexible logging framework for Java.<br>
<a href="http://logback.qos.ch" target="_blank">http://logback.qos.ch</a><o:p></o:p></p>

</div>

</div>

<p class=MsoNormal>--------------------------------------------------------------------------<o:p></o:p></p>

<div>

<div>

<p class=MsoNormal>NOTICE: If received in error, please destroy and notify
sender. Sender does not intend to waive confidentiality or privilege. Use of
this email is prohibited when received in error.<br>
_______________________________________________<br>
logback-dev mailing list<br>
logback-dev@qos.ch<br>
<a href="http://qos.ch/mailman/listinfo/logback-dev" target="_blank">http://qos.ch/mailman/listinfo/logback-dev</a><o:p></o:p></p>

</div>

</div>

</div>

<p class=MsoNormal><o:p>&nbsp;</o:p></p>

</div>

</DIV>
<DIV>
<HR>
</DIV>
<P CLASS="BulletedList" STYLE="MARGIN: 0in 0in 0pt; TEXT-INDENT: 0in; mso-list: none; tab-stops: .5in"><SPAN STYLE="FONT-SIZE: 8pt; COLOR: gray; mso-bidi-font-family: Arial"><FONT COLOR="gray" FACE="Arial" SIZE="1">NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.</FONT></SPAN></P>
<DIV></DIV></BODY></HTML>