Integrating the WCF trace with the Logging Application Block

As part of the integration between WCF and EntLib 3.0, this last one comes with a nice feature to redirect the WCF trace to the logging application block. This is done by Entlib through a custom trace listener (system.diagnostics) that captures the trace generated by WCF, and then, transfer that trace to any of the EntLib's trace listeners (Logging application block) configured in the application.

The image below illustrates the approach used by EntLib.

 


The fact of executing an extra component to transfer the trace messages and the logging application block itself will add some overhead to the overall solution by sure. On the other hand, we can use many of the available features in the logging application block, such as formatters, filters and trace listeners. Regarding the trace listeners, they will allow us to store the trace in different storages, like databases, msmq and files to name a few. Since we can actually do the same with a custom trace listener in system.diagnostics, the real benefit here is that we can leverage one of listeners provided in EntLib without needing to write one from the scratch or centralize the application trace and WCF trace just in one place.

If want to still use the trace viewer tool provided in WCF (svctraceviewer.exe), the bad news is that this tool only supports xml files (It would be great to have a plugging architecture here to read the trace information from any storage). Therefore, we will have to store the trace in a valid xml format, and then build something to dump the trace to a xml file. Entlib comes with a trace listener XmlTraceListener that generates a xml file with the format expected by the svctraceviewer.exe tool.

The EntLib's trace listener to redirect the trace messages the Logging application block can be configured as follow

<system.diagnostics>

        <sharedListeners>

            <add name="EntLibListener" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.EntLibLoggingProxyTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging"/>

        </sharedListeners>

        <sources>

            <source name="System.ServiceModel" switchValue="Information, ActivityTracing" propagateActivity="true">

                <listeners>

                    <add name="EntLibListener"/>

                </listeners>

            </source>

        </sources>

 </system.diagnostics>

For this post, I will demostrate how to configure the XmlTraceListener that comes out of the box to generate the file expected by the trace viewer tool.

<loggingConfiguration name="Logging Application Block" tracingEnabled="true"

    defaultCategory="General" logWarningsWhenNoCategoriesMatch="true">

    <listeners>

        <add fileName="trace-xml.xml" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.XmlTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging"

        traceOutputOptions="None" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.XmlTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging"

        name="XML Trace Listener" />

 

    </listeners>

    <formatters>

    </formatters>

    <categorySources>

        <add switchValue="All" name="System.ServiceModel">

            <listeners>

                <add name="XML Trace Listener" />

            </listeners>

        </add>

 

    </categorySources>

    <specialSources>

        <allEvents switchValue="All" name="All Events" />

        <notProcessed switchValue="All" name="Unprocessed Category" />

        <errors switchValue="All" name="Logging Errors &amp; Warnings" />

    </specialSources>

 

</loggingConfiguration>

2 Comments

  • I don't see the point.

    So, you redirect WCF logging through a proxy trace listener, then through the logging application block, then into a special EntLib listener that logs back into the right XML format.

    Which is back where you started at, i.e. logging WCF to XML, without going through a hoop to get there.

    Why make things more complicated than they need to be?

    For that matter, the EntLib logging block people should have just built a listener for the database + MSMQ and not reinvent the wheel.

  • Please, provide source code

Comments have been disabled for this content.