Enterprise Library V5 Logging
-
Ok, I think I know the answer to this but I am looking for some validation/verification here… I am TRYING to use the latest Enterprise Library build, specifically the Logging functionality, to write out debug logs… I am running into cases where I am ending up with log files being written that have a GUID prepended onto the filename: trace.log 0ce735a7-8bb1-465c-8340-cee60f6cc0d2trace.log 89e76526-07ea-4154-bc1c-c4caba63de48trace.log From what I can tell this seems to be because the logging subsystem opens the log file and keeps it open. This means that any other logging statements that try to use that same file get a new file built with this goofy name, and their debug goes there. This seams really odd, but it seems to be what’s happening. In fact if you watch the debug output when you run in the IDE you actually see two exception being thrown as the initial write happens because apparently (I have not yet 100% validated this by reviewing the code myself) they logging writer system tries to grab a handle to a log stream and does not know that it needs to open the file until it catches that exception. Then, once it is open it hangs on to it and does not allow any other source use THAT stream, it opens new ones and logs to there. What I am trying to achieve seems simple… I want to use different message formats for different areas of the code, but write all the entries to the same file. It seems that unless I use the same formatter layout for all calls to the file, I end up creating a new file handle and writing my entries to a new file instead of writing all to the one I have specified. Anyone else seen this? Know a way around it? Yeah, I have heard it recommended that I just write out using MSMQ and then have one single reader grab that data and log it to a file, but that seems really overkill for what SHOULD be a simple multiple-writer, single-reader, type of process here. I can’t believe that the entire logging library is actually suffering from this junk code. It just seems dumb that they can’t internally just handle this multiple writer issue by implementing their own darn queue of messages between the input text stream readers and the output file writer.
-
Ok, I think I know the answer to this but I am looking for some validation/verification here… I am TRYING to use the latest Enterprise Library build, specifically the Logging functionality, to write out debug logs… I am running into cases where I am ending up with log files being written that have a GUID prepended onto the filename: trace.log 0ce735a7-8bb1-465c-8340-cee60f6cc0d2trace.log 89e76526-07ea-4154-bc1c-c4caba63de48trace.log From what I can tell this seems to be because the logging subsystem opens the log file and keeps it open. This means that any other logging statements that try to use that same file get a new file built with this goofy name, and their debug goes there. This seams really odd, but it seems to be what’s happening. In fact if you watch the debug output when you run in the IDE you actually see two exception being thrown as the initial write happens because apparently (I have not yet 100% validated this by reviewing the code myself) they logging writer system tries to grab a handle to a log stream and does not know that it needs to open the file until it catches that exception. Then, once it is open it hangs on to it and does not allow any other source use THAT stream, it opens new ones and logs to there. What I am trying to achieve seems simple… I want to use different message formats for different areas of the code, but write all the entries to the same file. It seems that unless I use the same formatter layout for all calls to the file, I end up creating a new file handle and writing my entries to a new file instead of writing all to the one I have specified. Anyone else seen this? Know a way around it? Yeah, I have heard it recommended that I just write out using MSMQ and then have one single reader grab that data and log it to a file, but that seems really overkill for what SHOULD be a simple multiple-writer, single-reader, type of process here. I can’t believe that the entire logging library is actually suffering from this junk code. It just seems dumb that they can’t internally just handle this multiple writer issue by implementing their own darn queue of messages between the input text stream readers and the output file writer.
-
Alhtough I have never seen this in EntLib 4.1, how about disposing the
Loggerafter call toWritemethod?"Your code will never work, Luc's always will.", Richard MacCutchan[^]
I am actually disposing of the writer and it is still happening. I am not making any direct calls tothe Logger in this case. I create an instance of the writer:
LogWriter writer;
writer = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();...and then I just make a call to the writer using one of the overloads...
writer.Write(message);
writer.Dispose();
. . .
writer.Write(message, categories);
writer.Dispose();The thing I want to do is use different formatted writers bassed upon the type of message I am writing, but have them all go to the same file.
-
I am actually disposing of the writer and it is still happening. I am not making any direct calls tothe Logger in this case. I create an instance of the writer:
LogWriter writer;
writer = EnterpriseLibraryContainer.Current.GetInstance<LogWriter>();...and then I just make a call to the writer using one of the overloads...
writer.Write(message);
writer.Dispose();
. . .
writer.Write(message, categories);
writer.Dispose();The thing I want to do is use different formatted writers bassed upon the type of message I am writing, but have them all go to the same file.
In that case, you might have missed something in configuration. Can you check if all listeners have a file name associated with them. I haven't seen this happenning so just guessing around what might have happenned.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
-
In that case, you might have missed something in configuration. Can you check if all listeners have a file name associated with them. I haven't seen this happenning so just guessing around what might have happenned.
"Your code will never work, Luc's always will.", Richard MacCutchan[^]
Yeah, they do... They are all writing to 'trace.log' and each one is connected to a formatter that knows how to write out the fields that get passed in. I even have them all connected to one inbound entry point, the 'All Events' category... I have a feeling that this is what is causing the multiple files to be opened up... If I just connect on Listener to the category and send in events formatted in that way so it sees the right format, it works fine, but I want to have different formats for my messages so I am trying to define different listeners and formatters. There does not seem to be a way to tie multiple formatters to a single Log without defining multiple Listeners. I had figured that I would just define different formatters and they would be used based upon what methods I called and what signatures that provided (made sense to me and would be how I would build it) but that doe snot seem to be the case.