Logging handler log file name

Topics: Exception Handling Application Block, Logging Application Block
Mar 31, 2008 at 12:02 PM
Hi,
Enterprise library 3.1: I have typical exception handling configuration (with logging handler for each exception type) and also logging application block. My logging application block is configured to save all information to rolling flat file named "log.log". Whenever my code writes information directly to the logger everything works just fine and been saved to the mentioned file. However, whenever my code call the exception handling block the logging handler is writing the exception info to a new file with some weird name (e.g. "84aa6894-3937-485b-a7cb-68228ef66527log"). My question is: why the exception handling logging provider is not saving all the information to the same file (log.log) as the logging block do? Shouldn't the logging provider use the logging configuration?
Thanks for your help.
May 16, 2008 at 9:23 AM

Hi,

I am also having the above issue. When there is only one log file defined for all categories, the exception handling application block creates a {GUID}logfile.log, appending a guid to the log file name. This is getting annoying as each application start creates a new one.

Is there a way around this? or is this a bug? I am using Ent Lib 3.1 without strong naming, so I can change the source if needed, if somebody can point me to the right direction. This is very vital in our project.

Thanks for all the help.

-AR

May 16, 2008 at 5:22 PM
Edited May 16, 2008 at 5:23 PM
This will be fixed in the next release. If you want to update the source code, you can modify the Assemble method in class LoggingExceptionHandlerAssembler so that it so that instead of doing this

  210             LogWriter writer

  211                 = (LogWriter)context.HeadOfChain.BuildUp(context, typeof(LogWriter), null, null);


does this


  210
             LogWriter writer

  211                 = Logger.Writer;


Fernando


anandraman wrote:

Hi,

I am also having the above issue. When there is only one log file defined for all categories, the exception handling application block creates a {GUID}logfile.log, appending a guid to the log file name. This is getting annoying as each application start creates a new one.

Is there a way around this? or is this a bug? I am using Ent Lib 3.1 without strong naming, so I can change the source if needed, if somebody can point me to the right direction. This is very vital in our project.

Thanks for all the help.

-AR




Jun 20, 2008 at 5:21 PM
Edited Jun 20, 2008 at 6:56 PM
I'm trying to use the Enterprise Library 4.0 May 2008 and I appear to have the same issue.  Was this fixed in 4.0 or will it be fixed later?  I tried finding the code referenced above but I couldn't locate it.

If it is not fixed, is there an ETA for when the next release will be out?  If not, where should I make the change to fix it until then?

I have 7 Category Sources and each has their own Flat File Listener defined with separate log files.  I am getting the initial event in the correct log file but all of the other events are using their own log file with the GUID at the front of the defined filename.

This all appeared to work when I had only 1 Category and 1 Flat File Listener but this project requires to have the separate categories.  We'd like it all to log to the same log file for each of the categories.

I think it is important to note that I am only using the LAB and not the EHAB.

Thanks,

Josh
Jun 23, 2008 at 2:02 PM
Hi Josh,

This is fixed in v4, but not using the same code snippet shown here; now it's a configurable option in the logging exception handler. However, this applies only to the combination of LAB and EHAB, which you noted is not your case.

Can you post the relevant snippet of your configuration file?

Thanks,
Fernando



joshmshrf wrote:
I'm trying to use the Enterprise Library 4.0 May 2008 and I appear to have the same issue.  Was this fixed in 4.0 or will it be fixed later?  I tried finding the code referenced above but I couldn't locate it.

If it is not fixed, is there an ETA for when the next release will be out?  If not, where should I make the change to fix it until then?

I have 7 Category Sources and each has their own Flat File Listener defined with separate log files.  I am getting the initial event in the correct log file but all of the other events are using their own log file with the GUID at the front of the defined filename.

This all appeared to work when I had only 1 Category and 1 Flat File Listener but this project requires to have the separate categories.  We'd like it all to log to the same log file for each of the categories.

I think it is important to note that I am only using the LAB and not the EHAB.

Thanks,

Josh



Jun 23, 2008 at 3:56 PM
Hi Fernando,

I was able to figure out the issue based on the change that was made to the EHAB and LAB.  I was doing the same thing that the "bug" reported and creating a new LogWriter each time my logging procedure was called.  I changed that to use a prior logwriter if one exists and it solved my problem.

Thanks for the reply,

Josh
Feb 13, 2009 at 9:13 AM
Hi Fernando,

Enterprise Library 4.0 May 2008 is for .net framework 3.5, and my application is using .net framework 2.0.
Do we have any patch release available for ELB 3.1 on .net framework 2.0 for this issue
or 
modifying the LoggingExceptionHandlerAssembler code is the only option left :-( ?

Thanks
Mathew
Feb 13, 2009 at 9:37 AM
Hi,

I cant seem to find one. as the discussion says i think that modifying the source code is the only choice if you want to stick with EL 3.1

Valiant Dudan
Global Technology and Solutions
Avanade, Inc.
entlib.support@avanade.com
Mar 18, 2009 at 9:57 PM
I am using EntLib 4.1. Using the Logging Handler from the Policy Injection Application Block alongside the Logger from the Logging Application Block also causes the creation of additional logging files. Of course, what I really want it to write logging output to the same file in sequencial order. It appears that if the PIAB came first, then it owns the logging file, if the LAB came first, then it own the logging file. Can someone help?

Here is the app.config file

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <section name="policyInjection" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.Configuration.PolicyInjectionSettings, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <section name="loggingConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.LoggingSettings, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
    <section name="dataConfiguration" type="Microsoft.Practices.EnterpriseLibrary.Data.Configuration.DatabaseSettings, Microsoft.Practices.EnterpriseLibrary.Data, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
  </configSections>
  <policyInjection>
    <policies>
      <add name="CSI Policy">
        <matchingRules>
          <add type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.MatchingRules.NamespaceMatchingRule, Microsoft.Practices.EnterpriseLibrary.PolicyInjection, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
            name="Namespace Matching Rule">
            <matches>
              <add match="Com.HP.App.CSI" ignoreCase="true" />
            </matches>
          </add>
        </matchingRules>
        <handlers>
          <add logBehavior="BeforeAndAfter" beforeMessage="Before" afterMessage="After"
            eventId="0" includeParameterValues="true" includeCallStack="false"
            includeCallTime="true" priority="-1" severity="Information"
            order="0" type="Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers.LogCallHandler, Microsoft.Practices.EnterpriseLibrary.PolicyInjection.CallHandlers, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
            name="Logging Handler">
            <categories>
              <add name="General" />
            </categories>
          </add>
        </handlers>
      </add>
    </policies>
  </policyInjection>
  <loggingConfiguration name="Logging Application Block" tracingEnabled="true"
    defaultCategory="General" logWarningsWhenNoCategoriesMatch="true">
    <listeners>
      <add fileName="c:\trace.log" header="----------------------------------------"
        footer="----------------------------------------" formatter="Text Formatter"
        listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FlatFileTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        traceOutputOptions="None" filter="All" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FlatFileTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="FlatFile TraceListener" />
      <add source="Enterprise Library Logging" formatter="Text Formatter"
        log="Application" machineName="" listenerDataType="Microsoft.Practices.EnterpriseLibrary.Logging.Configuration.FormattedEventLogTraceListenerData, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        traceOutputOptions="None" filter="All" type="Microsoft.Practices.EnterpriseLibrary.Logging.TraceListeners.FormattedEventLogTraceListener, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="Formatted EventLog TraceListener" />
    </listeners>
    <formatters>
      <add template="Timestamp: {timestamp}&#xD;&#xA;Message: {message}&#xD;&#xA;Category: {category}&#xD;&#xA;Priority: {priority}&#xD;&#xA;EventId: {eventid}&#xD;&#xA;Severity: {severity}&#xD;&#xA;Title:{title}&#xD;&#xA;Machine: {machine}&#xD;&#xA;Application Domain: {appDomain}&#xD;&#xA;Process Id: {processId}&#xD;&#xA;Process Name: {processName}&#xD;&#xA;Win32 Thread Id: {win32ThreadId}&#xD;&#xA;Thread Name: {threadName}&#xD;&#xA;Extended Properties: {dictionary({key} - {value}&#xD;&#xA;)}"
        type="Microsoft.Practices.EnterpriseLibrary.Logging.Formatters.TextFormatter, Microsoft.Practices.EnterpriseLibrary.Logging, Version=4.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
        name="Text Formatter" />
    </formatters>
    <categorySources>
      <add switchValue="All" name="General">
        <listeners>
          <add name="FlatFile TraceListener" />
          <add name="Formatted EventLog TraceListener" />
        </listeners>
      </add>
    </categorySources>
    <specialSources>
      <allEvents switchValue="All" name="All Events" />
      <notProcessed switchValue="All" name="Unprocessed Category" />
      <errors switchValue="All" name="Logging Errors &amp; Warnings">
        <listeners>
          <add name="FlatFile TraceListener" />
          <add name="Formatted EventLog TraceListener" />
        </listeners>
      </errors>
    </specialSources>
  </loggingConfiguration>
</configuration>
Mar 19, 2009 at 6:18 AM
Refer to this thread.  The case is somewhat different but the idea is the same, http://www.codeplex.com/entlib/Thread/View.aspx?ThreadId=29703


Sarah Urmeneta
Global Technology & Solutions
Avanade, Inc.
entlib.support@avanade.com
Oct 29, 2010 at 1:39 PM

After going through the post , i'm still not sure of the solution to this issue. Appreciae if someone could assist.

 I'm using EL4.1 and .Net 3.5 . I 'm using both Logging Application Block (for logging )and Exception Application Block . I intend to use same log file (MyLog.log) for both Logging requirement as well as Exception Handling requirement. But my exception handler creates a new file with GUID appended to filename like 5c130571-e842-4e1e-9974-8bebe596c33cMyLog.log

Oct 29, 2010 at 4:15 PM

The solution is to use Enterprise Library's Distributor Service.   The behavior which adds a guid in the filename is inherent to .NET's TextWriterTraceListener.  The Distributor Service provides a mechanism for distributing your logs to a central location.  In your app, you will use MSMQ Trace listeners instead of a Flat File Trace Listener.   The MSMQ Trace listeners are configured to log to a specific queue.  You will then configure the Distributor Service pick up messages from that queue and it takes care of re-routing those messages to the correct destination.  The important thing is to configure MsmqDistributor.exe.config to contain the same logging categories as with those that are defined in your application's configuration which has the msmq trace listeners.  Read more on the distributor service for the detailed steps on how to use it.

 

Sarah Urmeneta
Global Technologies & Solutions
Avanade, Inc.
entlib.support@avanade.com

Nov 22, 2010 at 7:19 PM

Hi,

We're using EntLib 5.0 with a WCF web service hosted by IIS 6.  There are mutiple .svc services in the virtual directory.  Our logging configuration uses multiple Rolling Flat File Trace Listeners each with their own log file (no log files are shared by different trace listeners).  There is one trace listener per .svc file in the virtual directory.  We're running into this problem where GUIDs are prefixed onto file names and we'd like to have this corrected.  As each trace listener is uses it's own log file, we're unsure as to the cause of the problem. We did not have this problem in QA but we're having it in production...likely due to higher server loads.

This web service has multiple worker threads.  Could this be the cause of the problem? Is each worker thread has it's own instance of the same trace listener?  We'd like to avoid using a distributor service if possible. 

If we use a static instance of a LogWriter in our code, would that work?  I'm guessing not since each worker process runs on an independent thread.

Thanks,

Jason

Nov 22, 2010 at 7:34 PM
Edited Nov 22, 2010 at 8:00 PM

Hi again,

Just to add another piece of information.  Right now we obtain an instance of LogWriter by using the following code instead of using Logger.  Would that be a problem?  I thought the use of Logger was being deprecated so I didn't use it.  It's a bit hard to push this change into production just to test out this theory so advance information would be appreciated.

LogWriter logWriter = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();

Thanks

Nov 23, 2010 at 1:54 AM

It won't be a problem and in fact, it is the recommended approach for testability purposes.  And regarding on your problem, I'm afraid the only workaround I know of is to use the Distributor Service.  Even if  each trace listener has it's own log file, concurrent access to that file still happens.

 

Sarah Urmeneta
Global Technologies & Solutions
Avanade, Inc.
entlib.support@avanade.com