gmane.comp.apache.logging.log4net.devel

[jira] Closed: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Steven Myron (JIRA — 2008-08-27T15:05:44

[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Myron closed LOG4NET-171. -------------------------------- Resolution: Invalid Please see my last comment

[jira] Commented: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Steven Myron (JIRA — 2008-08-27T15:03:44

[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12626147#action_12626147 ] Steven Myron commented on LOG4NET-171: -------------------------------------- I guess that can be somewhat tricky to manage when Process A is trying to write to a file object while Process B is in the middle of rolling the file...right back to inter-process communication...you first! Since out program is a console application and is running at a client site, we assumed this was an unhandled error. It is good that this is only a benign System.Console.Out.Write... and no logging on that thread will occur (which is no problem). We did go with the following to split up some of the logging: The above log file naming schema still rolls and archives the logs (which is a good thing). The only catch was that we had to

[jira] Commented: (LOG4NET-10) Add %v pattern to output assembly version

Mark Mitchell (JIRA — 2008-08-27T02:55:44

[ https://issues.apache.org/jira/browse/LOG4NET-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625958#action_12625958 ] Mark Mitchell commented on LOG4NET-10: -------------------------------------- Ron, You are right -- I added the assembly information about the logging repository. I think adding the assembly information about the calling code is the goal, but may not be simple to implement in an efficient way. The reason I implemented the assembly information about the repository is to support the following use case (which I think covers most of the uses of this type of feature): public class X { private static final ILog logger = LogManager.getLogger(typeof(X)); ... } Whenever the logger in the example above calls a log method, the assembly information I store in the logger repository is the same as the assembly for class X, and thus whenever logger outputs log messages, the proper assembly information from it is displayed. The information d

[jira] Updated: (LOG4NET-172) Web Service Appender

Brandon Wood (JIRA — 2008-08-26T18:30:46

[ https://issues.apache.org/jira/browse/LOG4NET-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brandon Wood updated LOG4NET-172: --------------------------------- Attachment: WebServiceAppender.cs

[jira] Created: (LOG4NET-172) Web Service Appender

Brandon Wood (JIRA — 2008-08-26T18:30:46

Web Service Appender -------------------- Key: LOG4NET-172 URL: https://issues.apache.org/jira/browse/LOG4NET-172 Project: Log4net Issue Type: New Feature Components: Appenders Reporter: Brandon Wood Priority: Minor Attachments: WebServiceAppender.cs I have created a web service appender for a project I'm working on, and would like to contribute the code to log4net.

[jira] Commented: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Ron Grabowski (JIRA — 2008-08-25T22:15:44

[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625533#action_12625533 ] Ron Grabowski commented on LOG4NET-171: --------------------------------------- The problem is that you have two different procesess trying to write/roll the same file. If there are 3 processes writing/rolling the same file how does log4net know when one of the other processes has rolled the file? Log4net can easily handle lots of threads from the same process writing to a rolling file. The message you're seeing shouldn't be crashing your application. Log4net writes debug information to Console.Out when something bad happens. Your program should continue to function...but logging will be disabled. The next version of log4net has an improved configuration system that makes it easier to detect configuration errors. Until then you can turn on internal debugging and capture output sent to a System.Diagnostics listener. If the jobs do over

[jira] Commented: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Steven Myron (JIRA — 2008-08-25T13:35:44

[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625355#action_12625355 ] Steven Myron commented on LOG4NET-171: -------------------------------------- We are trying to work with the client and get the jobs spaced out so they don't have the potential to overlap. This is for a SAP integration project that syncs up data between two disparate systems. I had been using log4j in a web app environment that had multiple sessions, servlets, and threads logging to the same file in a high volume usage scenerio. We never had any problems with the logging (our hands were full with other issues). We also used a RollingFileAppender (on date/time rather than size). The Apache website states that is logging is fail-stop and not reliable and if logging is interrupted (database connection, network, "file sharing violation", etc.) that the worst case is that it just doesn't log that event (no problem). Right now, I am trying

[jira] Resolved: (LOG4NET-116) allow smtp to ssl authenticate and with certificates.

Ron Grabowski (JIRA — 2008-08-24T17:21:44

[ https://issues.apache.org/jira/browse/LOG4NET-116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-116. ----------------------------------- Resolution: Fixed Fixed in r667802.

svn commit: r688531 - in /logging/log4net/trunk/src: Core/TimeEvaluator.cs log4net.vs2005.csproj

2008-08-24T17:17:25

Author: rgrabowski Date: Sun Aug 24 10:17:25 2008 New Revision: 688531 URL: http://svn.apache.org/viewvc?rev=688531&view=rev Log: Fix for LOG4NET-155. Added TimeEvaluator that will trigger a buffer flush if a certain amount of time has elapsed since the last event. Added: logging/log4net/trunk/src/Core/TimeEvaluator.cs Modified: logging/log4net/trunk/src/log4net.vs2005.csproj Added: logging/log4net/trunk/src/Core/TimeEvaluator.cs URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/Core/TimeEvaluator.cs?rev=688531&view=auto ============================================================================== --- logging/log4net/trunk/src/Core/TimeEvaluator.cs (added) +++ logging/log4net/trunk/src/Core/TimeEvaluator.cs Sun Aug 24 10:17:25 2008 < at >< at > -0,0 +1,147 < at >< at > +#region Copyright & License +// +// Copyright 2001-2005 The Apache Software Foundation +// +// Licensed under the Apache License, Version 2.0 (the "License"); +// you may not use this file except in compliance with the License. +// You may

[jira] Resolved: (LOG4NET-155) Add TimeEvaluator

Ron Grabowski (JIRA — 2008-08-24T17:17:44

[ https://issues.apache.org/jira/browse/LOG4NET-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-155. ----------------------------------- Resolution: Fixed Fixed in r688531.

[jira] Resolved: (LOG4NET-158) XMLConfigurator.ConfigureAndWatch() leaks resources if called multiple times

Ron Grabowski (JIRA — 2008-08-24T17:01:44

[ https://issues.apache.org/jira/browse/LOG4NET-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-158. ----------------------------------- Resolution: Fixed Fixed in r688527

svn commit: r688527 - /logging/log4net/trunk/src/Config/XmlConfigurator.cs

2008-08-24T17:00:03

Author: rgrabowski Date: Sun Aug 24 10:00:02 2008 New Revision: 688527 URL: http://svn.apache.org/viewvc?rev=688527&view=rev Log: Fix for LOG4NET-158. XMLConfigurator.ConfigureAndWatch() won't leak resources when called multiple times. Internal FileWatcher is properly disposed when a change is detected. Modified: logging/log4net/trunk/src/Config/XmlConfigurator.cs Modified: logging/log4net/trunk/src/Config/XmlConfigurator.cs URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/Config/XmlConfigurator.cs?rev=688527&r1=688526&r2=688527&view=diff ============================================================================== --- logging/log4net/trunk/src/Config/XmlConfigurator.cs (original) +++ logging/log4net/trunk/src/Config/XmlConfigurator.cs Sun Aug 24 10:00:02 2008 < at >< at > -870,9 +870,23 < at >< at > try { -// Create a watch handler that will reload the -// configuration whenever the config file is modified. -ConfigureAndWatchHandler.StartWatching(repository, configFile); +

[jira] Resolved: (LOG4NET-123) [PATCH] EnvironmentPatternConverter does not expand User or System level environment variables under Windows

Ron Grabowski (JIRA — 2008-08-24T16:45:44

[ https://issues.apache.org/jira/browse/LOG4NET-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-123. ----------------------------------- Resolution: Fixed Fixed in r608300.

[jira] Commented: (LOG4NET-146) System.NullReferenceException on FindAndRender object

Ron Grabowski (JIRA — 2008-08-24T16:41:44

[ https://issues.apache.org/jira/browse/LOG4NET-146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625183#action_12625183 ] Ron Grabowski commented on LOG4NET-146: --------------------------------------- Is this still an issue with the latest version of the Oracle drivers?

[jira] Resolved: (LOG4NET-126) Links on the log4net Examples page do not work, including the overview link explaining why the other links do not work

Ron Grabowski (JIRA — 2008-08-24T15:43:44

[ https://issues.apache.org/jira/browse/LOG4NET-126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-126. ----------------------------------- Resolution: Fixed Fixed in r688521.

svn commit: r688521 - /logging/log4net/trunk/xdocs/src/release/example-apps.xml

2008-08-24T15:42:33

Author: rgrabowski Date: Sun Aug 24 08:42:32 2008 New Revision: 688521 URL: http://svn.apache.org/viewvc?rev=688521&view=rev Log: Fix for LOG4NET-126. Changed link to downloads page from "downloads.html" to "download.html". Modified: logging/log4net/trunk/xdocs/src/release/example-apps.xml Modified: logging/log4net/trunk/xdocs/src/release/example-apps.xml URL: http://svn.apache.org/viewvc/logging/log4net/trunk/xdocs/src/release/example-apps.xml?rev=688521&r1=688520&r2=688521&view=diff ============================================================================== --- logging/log4net/trunk/xdocs/src/release/example-apps.xml (original) +++ logging/log4net/trunk/xdocs/src/release/example-apps.xml Sun Aug 24 08:42:32 2008 < at >< at > -63,7 +63,7 < at >< at >

The following examples are only available in the log4net release download, not - on-line. To obtain the examples download

[jira] Resolved: (LOG4NET-153) Make it easier to configure multiple appenders in code using BasicConfigurator

Ron Grabowski (JIRA — 2008-08-24T15:39:44
[ https://issues.apache.org/jira/browse/LOG4NET-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-153. ----------------------------------- Resolution: Fixed Fixed in r653963.

[jira] Resolved: (LOG4NET-137) log4net.Filter.LevelMatchFilter does not work anymore

Ron Grabowski (JIRA — 2008-08-24T15:37:44
[ https://issues.apache.org/jira/browse/LOG4NET-137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-137. ----------------------------------- Resolution: Invalid Adding a DenyAllFilter should fix this issue.

[jira] Commented: (LOG4NET-10) Add %v pattern to output assembly version

Ron Grabowski (JIRA — 2008-08-24T15:35:45
[ https://issues.apache.org/jira/browse/LOG4NET-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625174#action_12625174 ] Ron Grabowski commented on LOG4NET-10: -------------------------------------- Mark, I looked at your patch and started writing some test cases and realized that you added support for storing assembly information about the repository. I think what Daniel and Nicko were talking about was wanting to add assembly information from where the log event was generated. For example: log.Info("Hello World"); What version of the Company.BusinessLayer assembly did that come from? Company.BusinessLayer, Version=1.2.3.4, Culture=neutral, PublicKeyToken=null Company.BusinessLayer, Version=1.2.3.5, Culture=neutral, PublicKeyToken=null Daniel's suggestion about "a single static call per-class using logging" seems to hint that when the first logging event is generated from the class we capture information from the calling assembly. In other words, I

[jira] Issue Comment Edited: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Ron Grabowski (JIRA — 2008-08-23T21:45:44
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625113#action_12625113 ] ron edited comment on LOG4NET-171 at 8/23/08 2:44 PM: ---------------------------------------------------------------- If you have a process running and it has an exclusive lock on a file and another process comes along and tries to get the lock it won't be able to get it. log4net isn't a database...it doesn't coordinate many processes trying to update a single resource. How do you propose it should handle this scenario? Having two processes writing to the same rolling file is generally not a good idea. How would the two processes communicate when/how to role the file? Can you append the process id to the filename so there isn't a conflict? You could use a normal FileAppender and a MutextLock (see the mailing list for sample code) that would allow two processes to write to the same file. was (Author: ron): If you have a proc

[jira] Commented: (LOG4NET-171) Log file locking causing an error to be thrown from the RollingFileAppender

Ron Grabowski (JIRA — 2008-08-23T21:43:44
[ https://issues.apache.org/jira/browse/LOG4NET-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625113#action_12625113 ] Ron Grabowski commented on LOG4NET-171: --------------------------------------- If you have a process running and it has an exclusive lock on a file and another process comes along and tries to get the lock it won't be able to get it. Having two processes writing to the same rolling file is generally not a good idea. How would the two processes communicate when/how to role the file? Can you append the process id to the filename so there isn't a conflict? You could use a normal FileAppender and a MutextLock (see the mailing list for sample code) that would allow two processes to write to the same file.