[jira] [Updated] (LOG4NET-129) EventLogAppender EventID parsing does not handle Active Properties properly
[
https://issues.apache.org/jira/browse/LOG4NET-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-129:
---
Affects Version/s: (was: 1.2.11)
Fix Version/s: 1.2.11
EventLogAppender EventID parsing does not handle Active Properties properly
---
Key: LOG4NET-129
URL: https://issues.apache.org/jira/browse/LOG4NET-129
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Reporter: Michael Christensen
Priority: Minor
Fix For: 1.2.11
Attachments: EventLogAppender.patch
The EventLogAppender supports setting the EventID of the Event being logged
through Context Properties, as described here:
http://www.mail-archive.com/log4net-user@logging.apache.org/msg02396.html
However, since GlobalContext is inappropriate for storing the EventID (as it
is likely to be specific for any given individual call to Log) and
ThreadContext cannot be used reliably when running in the context of ASP.NET
(since ASP.NET might switch the request between threads during execution, as
outlined here:
http://piers7.blogspot.com/2005/12/log4net-context-problems-with-aspnet.html
), it would be nice to be able to use an Active Property instead (which
could, for instance, delegate calls for the EventID to data stored in
HttpContext)
Unfortunately, this does not work, since the EventLogAppender assumes that
the Context Property holding the EventID is either int or string. The
relevant code is found in EventLogAppender.cs, in the override protected void
Append(LoggingEvent loggingEvent) method:
if (eventIDPropertyObj is int)
{
eventID = (int)eventIDPropertyObj;
}
else
{
string eventIDPropertyString = eventIDPropertyObj as string;
}
Any Active Property object will end up as null through the as string call,
and be ignored.
Suggested naive fix: If eventIDPropertyString is non-null and of other type
than int or string, call ToString() on the object and TryParse as int. Or use
whatever handling of Active Properties found elsewhere in log4net.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-132) Environment variables are mistakenly case sensitive on windows
[ https://issues.apache.org/jira/browse/LOG4NET-132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-132: --- Fix Version/s: 1.2 Maintenance Release Environment variables are mistakenly case sensitive on windows -- Key: LOG4NET-132 URL: https://issues.apache.org/jira/browse/LOG4NET-132 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows, .Net 3.5 Reporter: Matthew Gabeler-Lee Priority: Minor Fix For: 1.2 Maintenance Release On windows, environment variables are meant to be case insensitive. Because of this, in some contexts, a special IDictionary class that lowercases all the keys is used to manipulate environment variables, specifically ProcessStartInfo.EnvironmentVariables. The upshot of this, for me, is that when running under the profiler I have, all the environment variables get lowercased, and my logging configuration is broken, because TEMP is now temp, and log4net is treating the environment variables in a case sensitive manner, from using Environment.GetEnvironmentVariables(), which creates a normal case sensitive Hashtable object. It seems that, on windows, the result of Environment.GetEnvironmentVariables() should be copied into a StringDictionary to get proper case insensitive behavior. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-130) AdoNetAppender fails to insert the correct timestamp when logging from a web service.
[
https://issues.apache.org/jira/browse/LOG4NET-130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-130:
---
Fix Version/s: 1.2 Maintenance Release
AdoNetAppender fails to insert the correct timestamp when logging from a web
service.
-
Key: LOG4NET-130
URL: https://issues.apache.org/jira/browse/LOG4NET-130
Project: Log4net
Issue Type: Bug
Components: Appenders
Environment: C# web service running on Windows Server 2003 using the
.Net 2.0 Framework.
Reporter: Matthew Lee
Fix For: 1.2 Maintenance Release
I have a C# console application which calls a C# web service. Both
applications are written under the .Net 2.0 Framework. Both applications are
using a global xml configuration file, which is loaded via the
XmlConfigurator. The configuration uses 2 appenders, the AdoNetAppender and
the EventLogAppender.
The global configuration file that I mentioned earlier is an xml file that
is hosted by our local web server. Each application takes the configuration
file from the URL specified. Then each application injects its own name in
the ApplicationName section of the EventLogAppender. This is done so that
the names in the EventLog are meaningful instead of having a GUID for the
application name.
The code looks like this:
private static readonly log4net.ILog oLog =
log4net.LogManager.GetLogger(System.Reflection.MethodBase.GetCurrentMethod().DeclaringType);
static int Main(string[] args)
{
/***/
// Setup the log4net configuration. Here we'll use a cool trick.
// Log4net can be setup to load it's settings from an xml document
// which we'll get from a URL. This allows us to update the
config
// whenever we want to without redeploying individual programs.
/***/
XmlDocument oDoc = new XmlDocument();
oDoc.Load(Properties.Settings.Default.log4net_config_url);
foreach (XmlNode oNode in
oDoc.SelectNodes(log4net/appender[@name='EventLogAppender']))
{
if (oNode != null)
{
XmlAttribute oValueAttribute =
oDoc.CreateAttribute(value);
oValueAttribute.Value = oLog.Logger.Name.ToString();
XmlNode oNameNode =
oDoc.CreateNode(XmlNodeType.Element, applicationName, );
oNameNode.Attributes.Append(oValueAttribute);
oNode.AppendChild(oNameNode);
}
}
log4net.Config.XmlConfigurator.Configure(oDoc.DocumentElement);
The problems that I am having are that:
1.If the web service is not loaded in memory, the first call to the web
service does not log anything to the database. I do, however, get events in
the Application Event Log on the web server.
2.After the first call to the web service, on subseqent web service calls
the AdoNetAppender inserts records with timestamps left over from the prvious
call. So for example, if I call the web service for the first time at 1:22;
nothing is inserted into the database from the web service. If my second
call is at 1:26, the records that the web service inserts have a timestamp of
1:22. If I call the web service a 3rd time at 1:29, the records the web
service insert have a timestamp of 1:26.
3.Changes to hosted XML file (which are then read by the XmlConfigurator)
do not take effect until the web service is reloaded in IIS. I do have the
[assembly: log4net.Config.XmlConfigurator(Watch = true)] flag set. But, I'm
guessing that because the assembly stays loaded in IIS, this doesn't really
have much effect.
I suspect that the problems in #1 and #2 are defects of the AdoNetAppender.
I suspect that problem #3 is something that I'll have to live with.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-133) Unable to use default config loading
[ https://issues.apache.org/jira/browse/LOG4NET-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-133: --- Fix Version/s: 1.2 Maintenance Release Unable to use default config loading Key: LOG4NET-133 URL: https://issues.apache.org/jira/browse/LOG4NET-133 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Reporter: Manuel Riezebosch Fix For: 1.2 Maintenance Release Default config loading from app.config with the Log4NetConfigSectionHandler is not possible, because XmlConfiguratior.Configure(ILoggerRepository repository), where the ConfigurationManager is used, never gets called. The DefaultRepositorySelector.ConfigureRepository only loads config when the (Xml)ConfiguratorAttribute is found in the loaded assembly and calls Configure(assembly, repository) on this attribute. When using the XmlConfiguratorAttribute, the XmlConfigurator.Configure(targetRepository, configFile) gets called, which doesn't use the ConfigurationManager but an XmlDocument instead. The most annoying thing is that you are required now to use the XmlConfiguratorAttribute on assembly level, because otherwise the configuration is ignored. See DefaultRepositorySelector line 657 for more details. This is a problem when using calling functions in external assemblies, for instance with unit testing, because the logging from the tested object is ignored because the configuration fails to load. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-143) Invalid Repository Config Uri composition from log4net.Config application setting
[ https://issues.apache.org/jira/browse/LOG4NET-143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-143: --- Fix Version/s: 1.2.11 Invalid Repository Config Uri composition from log4net.Config application setting --- Key: LOG4NET-143 URL: https://issues.apache.org/jira/browse/LOG4NET-143 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Reporter: Eduard Gomolyako Priority: Trivial Fix For: 1.2.11 Attachments: Fix.jpg In DefaultRepositorySelector class in method ConfigureRepository(Assembly assembly, ILoggerRepository repository) (DefaultRepositorySelector.cs, line 706) code perform config uri composition from applicationBaseDirectory path and specified in log4net.Config settings file name. Because SystemInfo.ApplicationBaseDirectory property return path not ended with slash '\' at line 706 during new Uri(applicationBaseDirectory) operation executed trimmed last folder, so config uri made invalid. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LOG4NET-144) Attempted to append to closed appender named appenderName.
[
https://issues.apache.org/jira/browse/LOG4NET-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig closed LOG4NET-144.
--
Resolution: Cannot Reproduce
follwoing up on Ron's threat made three years ago ;-)
Attempted to append to closed appender named appenderName.
Key: LOG4NET-144
URL: https://issues.apache.org/jira/browse/LOG4NET-144
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: .net 2.0, WinXP, VS2005
Reporter: Andreas Aigner
Priority: Minor
Attachments: log4net.config
using following conifg-file:
?xml version=1.0 encoding=utf-8 ?
!--
.log4net configuration file
--
configuration
!-- This section contains the log4net configuration settings --
log4net debug=true
!-- Define some output appenders --
appender name=ConsoleAppender type=log4net.Appender.ConsoleAppender
layout type=log4net.Layout.PatternLayout
conversionPattern value=%date [%thread] %-5level %logger
[%property{Auftrag}] - %message%newline /
/layout
/appender
appender name=BufferingForwardingAppender
type=log4net.Appender.BufferingForwardingAppender
filter type=log4net.Filter.LevelRangeFilter
levelMin value=INFO /
levelMax value=FATAL /
/filter
bufferSize value=5/
appender-ref ref=ConsoleAppender /
/appender
!-- Setup the logger category, add the appenders and set the default
priority --
logger name=testLogger1
additivity value=false /
level value=DEBUG /
appender-ref ref=BufferingForwardingAppender /
/logger
logger name=testLogger2
additivity value=false /
level value=INFO /
appender-ref ref=BufferingForwardingAppender /
/logger
/log4net
/configuration
all messages from testlogger1 and testLogger2 appear on the Console.
After deleting this section:
logger name=testLogger2
additivity value=false /
level value=INFO /
appender-ref ref=BufferingForwardingAppender /
/logger
this ErrorCode appear on the console:
log4net:ERROR [BufferingForwardingAppender] Attempted to append to closed
appender named [BufferingForwardingAppender].
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-148) ThreadContext uses LocalDataStore to store ThreadSpecific data instead should be using [ThreadStatic] variables.
[ https://issues.apache.org/jira/browse/LOG4NET-148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-148: --- Fix Version/s: 1.2 Maintenance Release ThreadContext uses LocalDataStore to store ThreadSpecific data instead should be using [ThreadStatic] variables. - Key: LOG4NET-148 URL: https://issues.apache.org/jira/browse/LOG4NET-148 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.9, 1.2.10 Environment: .Net Framework Reporter: Hernando Torres-Rocca Priority: Critical Fix For: 1.2 Maintenance Release According to this article (http://blogs.msdn.com/junfeng/archive/2005/12/31/508423.aspx) and production issues encountered: using LocalDataStore is not a scalable approach for any web server that gets a significant amount of traffic. The ThreadContext object should be modified to use [ThreadStatic] variables. From the article: The Whidbey RTM implementation of Thread.GetData/Thread.SetData has several scalability issues caused by global locks being taken. The appdomain-global lock taken in LocalDataStore.SetData is one of them. There is another global lock taken in ThreadNative::GetDomainLocalStore that is even worse since it is process-global. The best workaround is to use [ThreadStatic] variables instead of Thread.GetData/Thread.SetData -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-162) It stops writing to the log file after certain threads are terminated and recreated.
[
https://issues.apache.org/jira/browse/LOG4NET-162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-162:
---
Fix Version/s: 1.2 Maintenance Release
we'd really need to see what the log4net internal debugging says
It stops writing to the log file after certain threads are terminated and
recreated.
Key: LOG4NET-162
URL: https://issues.apache.org/jira/browse/LOG4NET-162
Project: Log4net
Issue Type: Bug
Affects Versions: 1.2.10
Environment: C#, .net framework 3.0, VS2005, Windows XP, intel
pentium 4, 3 GHz, 1 GB RAM
Reporter: Amjad Khoja
Priority: Critical
Fix For: 1.2 Maintenance Release
Original Estimate: 10m
Remaining Estimate: 10m
We are using log4net in an windows service application, which spans number of
threads. Logging works perfect until we try to refresh the cache where we
terminate the threads and recreate it and in between the logging stops. When
debug we see that it goes to the logger print message statement and there is
no error but nothing gets written to the log file.
This behaviour is undpredictable as sometimes it works fine when it goes
through the complete refresh method.
Settings of Log4net in app.config is as follow.
log4net
appender name=ErrorAppender
type=log4net.Appender.RollingFileAppender
file value=C:\\ErrorNRTRDELogs\\NRTRDELogVPMNC.txt /
appendToFile value=true /
rollingStyle value=Size /
maxSizeRollBackups value=10 /
maximumFileSize value=10MB /
staticLogFileName value=true /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%-5p %d %5rms %-22.22c{1} %-18.18M - %m%n
/
/layout
/appender
logger name=ErrorLog
level value=DEBUG/
appender-ref ref=ErrorAppender/
/logger
/log4net
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-172) Web Service Appender
[ https://issues.apache.org/jira/browse/LOG4NET-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-172: --- Fix Version/s: 2.0 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 Fix For: 2.0 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. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-173) Request for NMS Appender
[ https://issues.apache.org/jira/browse/LOG4NET-173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-173: --- Fix Version/s: 1.2 Maintenance Release With an appender already available outside of log4net it may be good to create an area at log4net's website and point to third party appenders. I'm not sure what the benefit of adding the code to log4net would be as the appender had to be shipped in a separate assembly anyway - we wouldn't want to add a dependency on Apache.NMS.dll (and others) to log4net.dll. Request for NMS Appender Key: LOG4NET-173 URL: https://issues.apache.org/jira/browse/LOG4NET-173 Project: Log4net Issue Type: Wish Components: Appenders Reporter: Mark Keenan Priority: Minor Fix For: 1.2 Maintenance Release Based on some messages in the ActiveMQ forum, I believe the NMS developers are getting close to a 1.0 release. An NMS based appender for log4net would be extremely useful. I'm not sure how much of the JMS appender could be ported from log4j but maybe that's a good starting point? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-175) RollingFileAppender generates unexpected filename and/or causes IIS to hang
[
https://issues.apache.org/jira/browse/LOG4NET-175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-175:
---
Fix Version/s: 1.2 Maintenance Release
RollingFileAppender generates unexpected filename and/or causes IIS to hang
---
Key: LOG4NET-175
URL: https://issues.apache.org/jira/browse/LOG4NET-175
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.9
Environment: win32
Reporter: Devan Iyer
Fix For: 1.2 Maintenance Release
Original Estimate: 2h
Remaining Estimate: 2h
We are using rolling file appender in an IIS managed C# application. Our
log4Net deployment is configured with the following options specified in
basic.xml: appendToFile value=false / countDirection value=0 /
maximumFileSize value=512KB / maxSizeRollBackups value=100 /
rollingStyle value=Once / staticLogFileName value=false /. The file
pattern for our log file name is abc_%date{MMdd_HHmmss}_%processid_.log.
We have observed in our production environment that occasionally filenames
would be created with patterns like
abc_%date{MMdd_HHmmss}_%processid_.log.1,
abc_%date{MMdd_HHmmss}_%processid_.log.1.2,
abc_%date{MMdd_HHmmss}_%processid_.log.1.2.3, etc. We have observed
filenames with the dot+sequential numbers pattern after the .log to be
anything from .1 to .220. This is one of two unexpected behaviours
observed.
The second unexpected behaviour seems to a special case of the first that
occasionally causes IIS to hang (100% CPU consumption). An analysis of
several crash dumps taken at the time of the hang indicated that
RollingFileAppender had in memory a filename of the same pattern as above but
with the number of characters [base filename pattern]+[recurring extension
pattern] exceeding 255 characters. It is very likely that an attempt to
create a file by such name on NTFS would throw exceptions at various levels -
managed and native - and hence the file itself is never created.
To the best of our knowledge, there were no events to trigger the filename to
be rolled. As indicated in the configuration options, we are using
RollingStyle of Once. (The log file content is minimal at the time the
symptoms occur - total file size is about 2K - and the times of occurrence
are totally non related).
We have been unable to capture the workflow leading up to the symptoms above
due to the high number of users and document types in our production
environment. The permissions on the logging folder are static. However, we
have found a simple workflow in our lab environment, using permissions, that
produce similar symptoms. This workflow is:
- Right click on the logging folder and select Properties
- Under the Security tab ensure that IIS_WPG group doesn't have write
access to the logging folder.
- Restart IIS
- Launch our application and view a document. Check the logging folder to
make sure that a logfile is not created.
- View a few more documents
- Change the permission on the logging folder and ensure IIS_WPG group has
write access to the folder. DO NOT restart IIS after changing the permission.
- Launch our application and view another document.
- At this point a logfile with a filename pattern described will be found in
the logging folder.
As mentioned, it is unlikely that permissions are the trigger in our event
but it is likely that the same code is creating these unexpected patterns
irrespective of the trigger.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-178) Log4Net stops logging after appdomain recycle of aps.net2.0 application
[ https://issues.apache.org/jira/browse/LOG4NET-178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-178: --- Fix Version/s: 1.2 Maintenance Release Log4Net stops logging after appdomain recycle of aps.net2.0 application --- Key: LOG4NET-178 URL: https://issues.apache.org/jira/browse/LOG4NET-178 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows server 2003 Reporter: Richard Nijkamp Fix For: 1.2 Maintenance Release Dear sir/madam, We are using Log4Net 1.2.10. We encounter the problem that Log4net doesn't continue logging after an event that triggers an appdomain recycle/restart. In the global.asax we start the logging with: private static readonly ILog log = LogManager.GetLogger(MethodBase.GetCurrentMethod().DeclaringType); Logging works flawless when the application is started for the first time. After sometime it might occur that the appdomain gets recycled due to inactivity of the web application. We use the following code in Application_end(): log.Info(*** Application end ***); log4net.LogManager.Shutdown(); After this function the application gets restarted and the Application_start() method executes and writes new lines to the log. The problem is that the log4net doesn't write the new lines after the restart. Could you explain why log4net might stop working after an appdomain restart of an asp.net2.0 web application? If I want log4net to work properly again I need to restart IIS manually. Looking forward to your reply. Best regards, Richard Nijkamp -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-179) Log file does not get created by release version of App.exe
[ https://issues.apache.org/jira/browse/LOG4NET-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-179. Resolution: Cannot Reproduce Log file does not get created by release version of App.exe --- Key: LOG4NET-179 URL: https://issues.apache.org/jira/browse/LOG4NET-179 Project: Log4net Issue Type: Test Affects Versions: 1.2.10 Environment: Visual Studio 2005, language C#, OS Windows XP Professional Reporter: Shetal Shah I have a windows application that uses log4net. My app.config section has log4net appender name=RollingFileAppender type=log4net.Appender.RollingFileAppender file value=nul / appendToFile value=false / rollingStyle value=Size / maxSizeRollBackups value=10 / maximumFileSize value=2MB / layout type=log4net.Layout.PatternLayout param name=ConversionPattern value=%d [%t] %-5p %c [%x] - %m%n / /layout /appender root level value=ALL / appender-ref ref=RollingFileAppender / appender-ref ref=UdpAppender / /root /log4net When I build my exe in debug mode and run it, it works fine and log4net.Repository.ILoggerRepository RootRep; RootRep = log4net.LogManager.GetRepository(); RootRep is configured and has one appender. Now, same code but when I compile the exe in release mode, it does not create log file. RootRep is not configured and it has 0 appender. I am not sure what is different between debug and release exe. Any help is greatly appriciated. Thanks Shetal Shah -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-180) SMTPAppender not sending all emails
[
https://issues.apache.org/jira/browse/LOG4NET-180?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-180:
---
Fix Version/s: 1.2 Maintenance Release
SMTPAppender not sending all emails
---
Key: LOG4NET-180
URL: https://issues.apache.org/jira/browse/LOG4NET-180
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows XP with SP2, Visual Studio 2008 with SP1, C#, WCF
Reporter: Paul Speranza
Fix For: 1.2 Maintenance Release
I have a WCF IIS service application. hardly any of my SMTP emails are
getting sent out. TO be sure that it isn't my SMTP server I created a console
app that sends mail using System.Net.Mail and it works every time. I only
have log4net configured for SmtpAppender.
Here is the config.
log4net
appender name=SmtpAppender type=log4net.Appender.SmtpAppender
to value=t...@email.com /
from value=f...@email.com /
smtpHost value=127.0.0.1 /
subject value=An exception occurred in Services. /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%date [%thread] %-5level %logger [%ndc] -
%message%newline /
/layout
priority value=High /
/appender
!--root
level value=ALL /
appender-ref ref=SmtpAppender /
/root--
logger name=Services
level value=All /
appender-ref ref=SmtpAppender /
/logger
/log4net
PLUS
section name=log4net type=System.Configuration.IgnoreSectionHandler /
In my global asax I have
void Application_Start(object sender, EventArgs e)
{
log4net.Config.XmlConfigurator.Configure();
}
In my service implementation I have
private static readonly log4net.ILog _Logger =
log4net.LogManager.GetLogger(Services);
Where I am telling log4net to do its magic is
if (_Logger.IsErrorEnabled)
_Logger.Error(formattedException, exception);
I have no idea what this could be. I am brand new to log4net also.
Thnaks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-181) Have PatternString recognize %n just as PatternLayout recognizes it
[ https://issues.apache.org/jira/browse/LOG4NET-181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-181: --- Fix Version/s: 1.2 Maintenance Release Have PatternString recognize %n just as PatternLayout recognizes it --- Key: LOG4NET-181 URL: https://issues.apache.org/jira/browse/LOG4NET-181 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.10 Reporter: Chris Jerdonek Assignee: Ron Grabowski Priority: Minor Fix For: 1.2 Maintenance Release The log4net.Layout.PatternLayout class recognizes %n and %newline for newlines, but log4net.Util.PatternString recognizes only %newline. This may be a source of confusion for some people (and was for me temporarily). I don't know if there are other cases like this. If so, it might make sense to have both classes recognize the same conversion patterns -- for those patterns that would make sense in both contexts. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-182) LevelRangeFilter behavior doesn't match documentation; behavior and documentation are not as expected
[ https://issues.apache.org/jira/browse/LOG4NET-182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-182: --- Fix Version/s: 1.2 Maintenance Release LevelRangeFilter behavior doesn't match documentation; behavior and documentation are not as expected - Key: LOG4NET-182 URL: https://issues.apache.org/jira/browse/LOG4NET-182 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Reporter: Chris Jerdonek Priority: Minor Fix For: 1.2 Maintenance Release The LevelRangeFilter's behavior doesn't match what the documentation says. Also, neither the current behavior nor the documentation seem right. The log4net SDK Reference documentation says this about log4net.Filter.LevelRangeFilter: If there is a match between the range of priorities and the Level of the LoggingEvent, then the Decide method returns Accept in case the AcceptOnMatch option value is set to true, if it is false then Deny is returned. If there is no match, Deny is returned. The actual behavior seems to differ from this in the case of a match. If there is a match, it looks like the code returns Accept when AcceptOnMatch is true, and Neutral if AcceptOnMatch is false. I think both the documentation and behavior should be changed to the following: If there is a match between the range of priorities and the Level of the LoggingEvent, then the Decide method returns Accept if the AcceptOnMatch option is true, and Deny if the AcceptOnMatch option is false. If there is no match, Neutral is returned. This behavior seems more natural. It also parallels the behavior of the LevelMatchFilter. I believe this can be fixed simply by swapping occurrences of FilterDecision.Deny and FilterDecision.Neutral in the code for LevelRangeFilter.Decide -- and also adjusting the documentation as above. Thanks. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-183) Appender: RemoteSyslogAppender, semicolon persist if identity value is an empty string
[
https://issues.apache.org/jira/browse/LOG4NET-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-183:
---
Fix Version/s: 1.2 Maintenance Release
Appender: RemoteSyslogAppender, semicolon persist if identity value is an
empty string
--
Key: LOG4NET-183
URL: https://issues.apache.org/jira/browse/LOG4NET-183
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows XP, .Net 2.0
Reporter: Victor Munoz
Priority: Minor
Fix For: 1.2 Maintenance Release
Original Estimate: 24h
Remaining Estimate: 24h
Filename: RemolteSyslogAppender.cs
---
// Identity
if (m_identity != null)
{
m_identity.Format(writer, loggingEvent);
}
Else
{
writer.Write(loggingEvent.Domain);
}
writer.Write(: ); --- ALWAYS include
semicolon, even if identity is an empty string.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-185) Rolling files backups is not decreasing when updating MaxSizeRollBackups
[ https://issues.apache.org/jira/browse/LOG4NET-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-185: --- Fix Version/s: 1.2 Maintenance Release Personally I'm not convinced this really is a bug at all. Rolling files backups is not decreasing when updating MaxSizeRollBackups Key: LOG4NET-185 URL: https://issues.apache.org/jira/browse/LOG4NET-185 Project: Log4net Issue Type: Bug Affects Versions: 1.2.10 Environment: windows, all Reporter: nir bon Fix For: 1.2 Maintenance Release When decreasing the MaxSizeRollBackups parameter at runtime. the log4net is not deleting older files that has already written. This means that if i change the MaxSizeRollBackups parameter repeadetly, i can reach to very large number of old log files. reconstruct scenario ^^ set number of backups to 10 files. wait till you have 10 files. decrease number of backups to 2. result- 10 files will remain at disk. 8 files will never be deleted, 2 files will stay as retention. expected - only 2 files will remain in disk. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-184) Configuration Changes + XSD
[ https://issues.apache.org/jira/browse/LOG4NET-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-184: --- Fix Version/s: 1.2 Maintenance Release Configuration Changes + XSD --- Key: LOG4NET-184 URL: https://issues.apache.org/jira/browse/LOG4NET-184 Project: Log4net Issue Type: Wish Components: Core, Documentation Affects Versions: 1.2.10 Environment: n/a Reporter: Roger Knapp Priority: Minor Fix For: 1.2 Maintenance Release Original Estimate: 168h Remaining Estimate: 168h I'm a first-time user of log4net. At first impression the configuration is very overwhelming. Though I recognize the strength by it's flexibility, I think it's one of the weakest points of log4net. Some simple changes could allow a real XSD to be created and thus to verify configuration and provide helpful context help when tring to create them. I've worked to understand the current configuration and after reading the documentation and reverse engineering the code, I finally have an understanding what to do. It was a long and painful process and I wanted to share that experience with you only so that you could improve the experience for others. Namely, I want to suggest that the following change be allowed in future version. Rather than having the 'type=' attribute used on elements (appenders, filters, and layouts) that reflect a built-in component, I would recommend ADDING an alternative way of defining them by using the appender (or fitler/layout) name as the element name much like you already do with the 'param' and class properties. This allows for us to now create full validating XSD files. On the effort of creating an XSD file, I have made progress beyond what was previously available. You can find it at the following location: http://csharptest.net/downloads/schema/log4net.xsd I will be glad to transfer all rights to the project if and when it is distributed with the product. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-187) Add a Trace level with isTraceEnabled.
[ https://issues.apache.org/jira/browse/LOG4NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-187: --- Fix Version/s: 2.0 pushing back backwards incompatible changes Add a Trace level with isTraceEnabled. -- Key: LOG4NET-187 URL: https://issues.apache.org/jira/browse/LOG4NET-187 Project: Log4net Issue Type: New Feature Components: Core Affects Versions: 1.2.10 Reporter: Mihran Shahinian Fix For: 2.0 Attachments: patch Original Estimate: 24h Remaining Estimate: 24h I am adding a simple patch for a trace level logging. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-194) FileSystemWatcher for .Net Compact Framework
[ https://issues.apache.org/jira/browse/LOG4NET-194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-194: --- Fix Version/s: 1.2 Maintenance Release FileSystemWatcher for .Net Compact Framework Key: LOG4NET-194 URL: https://issues.apache.org/jira/browse/LOG4NET-194 Project: Log4net Issue Type: Improvement Components: Other Affects Versions: 1.2.10 Environment: .Net Compact Framework 1.0/2.0/3.5 Reporter: Lukasz Antoniak Priority: Minor Fix For: 1.2 Maintenance Release Attachments: Log4NetTest_20090210.zip, Modified_Files_20090210.zip, log4netcf.vs2008.dll, log4netcf.vs2008_20090210.zip Welcome! I would like to suggest an improvement of Log4Net utility for .Net Compact Framework. The .Net CF 1.0/2.0/3.5 does not provide developers with FileSystemWatcher class. However there is nothing against implementing a simple class invoking SHChangeNotifyRegister API in Log4Net. I have recently started developing mobile applications and I regret lack of automatic reconfiguration feature in Log4Net .Net CF. I am quite familiar with SHChangeNotifyRegister API and I could try to modify XmlConfigurator class to support configuration file monitoring. What do you think of this idea? If there was an opportunity, I would like to contribute to Log4Net project. Regards, Lukasz Antoniak -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-197) Download of 1.2.10 fails at 4.8M and zip does not open - therefore can't use s/w
[ https://issues.apache.org/jira/browse/LOG4NET-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-197. Resolution: Cannot Reproduce works for me right now. I'll note that log4net's download page is not using the proper ASF mirror setup and will rectify this by the time of the 1.2.11 release. Download of 1.2.10 fails at 4.8M and zip does not open - therefore can't use s/w Key: LOG4NET-197 URL: https://issues.apache.org/jira/browse/LOG4NET-197 Project: Log4net Issue Type: Task Components: Core Affects Versions: 1.2.10 Environment: IE7, Firefox, Vista Reporter: James Stewart Original Estimate: 0.5h Remaining Estimate: 0.5h Simply, the download from http://logging.apache.org/log4net/download.html is not working; the d/load fails at about 4.8M and so I can't use the s/w in any way. I also do not get a list of mirrors as suggested and can't find anywhere else to download from. Help! Apologies if this is not teh right place to report this, but it is a bit of a Blocker -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-198) Memory leak on a very basic code
[
https://issues.apache.org/jira/browse/LOG4NET-198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-198:
---
Fix Version/s: 1.2 Maintenance Release
Memory leak on a very basic code
Key: LOG4NET-198
URL: https://issues.apache.org/jira/browse/LOG4NET-198
Project: Log4net
Issue Type: Test
Components: Core
Affects Versions: 1.2.10
Environment: windows xp sp3
Reporter: rauzy
Fix For: 1.2 Maintenance Release
Attachments: WindowsFormsApplication1.zip
I build a simple form with a single button that start a timer execute every
second, the task of this timer is to execute the following line:
log.Debug(Hello);
and I observe a memory leak.
See Below.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Text;
using System.Windows.Forms;
using log4net;
using log4net.Config;
namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
private static readonly ILog log =
LogManager.GetLogger(typeof(Form1));
public Form1()
{
InitializeComponent();
}
private void button1_Click(object sender, EventArgs e)
{
XmlConfigurator.Configure();
FreqTimers.Start();
}
private void FreqTimers_Tick(object sender, EventArgs e)
{
log.Debug(demo);
}
}
}
with an app.config like
?xml version=1.0 encoding=utf-8 ?
configuration
configSections
section name=log4net
type=log4net.Config.Log4NetConfigurationSectionHandler, log4net /
/configSections
log4net debug=true
appender name=RollingLogFileAppender
type=log4net.Appender.RollingFileAppender
file value=C:\\Temp\\TestMailer.log /
appendToFile value=true /
rollingStyle value=Size /
maxSizeRollBackups value=10 /
maximumFileSize value=10MB /
staticLogFileName value=true /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%-5p %d - %m %-18.18M %n /
/layout
/appender
root
level value=DEBUG /
appender-ref ref=RollingLogFileAppender /
/root
/log4net
/configuration
If you monitor the application, you see that the memory usage increase. Why?
I can post the source solution if needed.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-201) Add asynchronous logging behavior
[ https://issues.apache.org/jira/browse/LOG4NET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-201: --- Fix Version/s: 1.2 Maintenance Release I'm pretty sure I've seen a different JIRA ticket for an async appender shortly, will tie them together later. Add asynchronous logging behavior - Key: LOG4NET-201 URL: https://issues.apache.org/jira/browse/LOG4NET-201 Project: Log4net Issue Type: New Feature Components: Core Environment: All Reporter: Jason Fix For: 1.2 Maintenance Release Attachments: log4net_trunk.zip This issue was first discussed in an e-mail conversation which I'll paste here: - Hi Ron, I'll open a JIRA ticket for this issue. I've only looked at log4net briefly (an hour before I started coding - needed a quick solution), so I'm happy to hear your input. My less knowledgeable inputs: * For the hierarchy level vs the logger level, I agree that the hierarchy level seems better. I didn't realize anything about the 'hierarchy' until later today. I only added the asynchronous behavior to the logger because I mistakenly thought that was the highest level. * I also realized that FixFlags.All would be slow by comparison to a partial 'Fix', but I hadn't yet figured out which fields were relevant. I'm still fuzzy on this as I'm not sure how to tell which fields are required - maybe inferred from the log level? This seems to be a big issue with the async behavior since it could potentially introduce more harm than good in the current implementation. * ThreadSafeBlockingQueue - I'd seen mention of IBulkAppenders but didn't know anymore than what I could infer from the names. I'm guessing these receive a collection of inputs. The TSBQueue could certainly be modified. I was going to create it with generics but I'm guessing log4net doesn't use generics to provide backwards compatibility? I'm interested to hear about your other solution since you seem to understand the overall design well. For now I need to get my application running on top of what I have, but I might be able to lend a hand on this issue going forward. Jason On 2/17/09, Ron Grabowski wrote: The best place to put your code would be on a new JIRA ticket and make sure to grant the ok to include into a ASF project. I've been thinking about a feature like this but I wanted to get the remaining tickets for the next version closed out (before 4.0 comes out!!!). My original plan was to Fix the events then dispatch them to another worker thread as soon as they arrived so the code would return to the caller as soon as possible. I was thinking more on the ILoggerRepository (Hiearchy) level as opposed to an individual Logger. The Logger level definietly offers more control but part of me things that people would be ok with either all loggers being sync (how it is today) or all-async...allowing them to change on a per Logger level might be too confusing ??? Plus if there's a Thread per Logger and there are a lot of Loggers won't there be a lot of Threads running? I suppose that's why you added a property on a per logger basis to control which specific loggers were async. ThreadSafeBlockingQueue.Dequeue(Queue) could dequeue the items into LoggingEvent[] to allow IBulkAppenders to better handle the items. When ForcedLogSub is called with FixFlags.All I think a StackTrace is capture (slow) even if none of the attached appenders use location information. Maybe add some checks to AddAppender to make a FixFlags that is All - LocationInfo. Its late, I have another solution that I'll write about tomorrow. From: Jason Aubrey Sent: Tuesday, February 17, 2009 12:13:26 PM Subject: Commit access requested for an asynchronous logging addition Hi, I just added a property to my working copy called 'Synchronous'. It's 'true' by default to maintain the current behavior. When 'false' the logger will queue log events in a thread safe queue that's serviced by a worker thread. The goal of asynchronous logging is to reduce the amount of time incurred by logging on the primary thread. This can be useful in applications such as in financial trading where time is quite literally money. It's realized that a data integrity risk is introduced by logging asynchronously, but this is a known and acceptable risk. I added the synchronous option within the logger instead of the appenders because the behavior should apply to all appenders. The new/modified files are attached within log4net_trunk.zip. I don't currently have commit access but I can commit the code if granted access.
[jira] [Updated] (LOG4NET-203) RollingFileAppender does not roll more than one time when PreserveLogFileNameExtension is true
[
https://issues.apache.org/jira/browse/LOG4NET-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-203:
---
Fix Version/s: 1.2 Maintenance Release
RollingFileAppender does not roll more than one time when
PreserveLogFileNameExtension is true
--
Key: LOG4NET-203
URL: https://issues.apache.org/jira/browse/LOG4NET-203
Project: Log4net
Issue Type: Bug
Components: Appenders
Environment: I'm using the trunk
Reporter: Scott Alexander
Fix For: 1.2 Maintenance Release
Method InitializeFromOneFile in RollingFileAppender.cs does not take into
account the file extension. To repro setup an appender like so
var appender = new DevicePointValueCsvAppender
{
MaxFileSize =
ConfigurationManager.AppSettings[MaxFileSizeName].IfNotNull(max =
OptionConverter.ToFileSize(max, DefaultMaxFileSize), DefaultMaxFileSize),
MaxSizeRollBackups = 6,//
ConfigurationManager.AppSettings[MaxSizeRollBackupsName].IfNotNull(max =
Int32.Parse(max), DefaultMaxSizeRollBackups),
Layout = new PatternLayout { ConversionPattern =
PatternLayout.DefaultConversionPattern },
File = String.Format(CultureInfo.InvariantCulture,
FileNameFormat, modbusMasterName),
RollingStyle = RollingFileAppender.RollingMode.Composite,
PreserveLogFileNameExtension = true,
StaticLogFileName = false,
AppendToFile = false
};
When the logger initializes the call to InitializeRollBackups is made whic
incorrectly calculates the pre-existing number of backups, due to the fact
that the file extension is being included in the following line
if (! curFileName.StartsWith(CombinePath(baseFile,
m_dateTime.Now.ToString(m_datePattern,
System.Globalization.DateTimeFormatInfo.InvariantInfo
The previous line should be replaced with something like the following
string baseComparison = CombinePath(baseFile,
m_dateTime.Now.ToString(m_datePattern,
System.Globalization.DateTimeFormatInfo.InvariantInfo));
if (m_preserveLogFileNameExtension)
baseComparison =
Path.GetFileNameWithoutExtension(baseComparison);
if (! curFileName.StartsWith(baseComparison))
Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-205) Allow filtering by Identity / UserName / ThreadName and Domain
[ https://issues.apache.org/jira/browse/LOG4NET-205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-205: --- Fix Version/s: 1.2 Maintenance Release Allow filtering by Identity / UserName / ThreadName and Domain -- Key: LOG4NET-205 URL: https://issues.apache.org/jira/browse/LOG4NET-205 Project: Log4net Issue Type: New Feature Components: Core Affects Versions: 1.2.10 Reporter: Bruno Baia Fix For: 1.2 Maintenance Release Background : See thread named PropertyFilter ( http://mail-archives.apache.org/mod_mbox/logging-log4net-user/200903.mbox/browser ) By default, there's no way to filter by those LoggingEvent properties. I want to avoid extra code to do that (by adding a property programmatically or implementing a custom IFilter) I see 2 solutions : - LoggingEvent.LookupProperty should be able to resolve internal keys like log4net:Identity, log4net:UserName, etc... (Note that It already works for log4net:HostName added by GlobalContext's static constructor). Then we can use the PropertyFilter. - Add a IFilter implementation for each property like it's done for the LoggerName and Level properties. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-204) Silverlight compiled binary
[ https://issues.apache.org/jira/browse/LOG4NET-204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-204: --- Fix Version/s: 1.2 Maintenance Release NAnt supports Silverlight 2.0 as a target but I'm sure there us more to it than just setting the correct target framework. Silverlight compiled binary --- Key: LOG4NET-204 URL: https://issues.apache.org/jira/browse/LOG4NET-204 Project: Log4net Issue Type: Wish Components: Builds, Examples Affects Versions: 1.2.10 Reporter: Trond Andersen Fix For: 1.2 Maintenance Release There should be a Silverlight build of log4net that can be used in Silverlight applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-209) XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement
[ https://issues.apache.org/jira/browse/LOG4NET-209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-209: --- Affects Version/s: (was: 1.2.11) Fix Version/s: 1.2.11 XmlLayout.FormatXml calls wrong overload of XmlWriter.WriteStartElement --- Key: LOG4NET-209 URL: https://issues.apache.org/jira/browse/LOG4NET-209 Project: Log4net Issue Type: Bug Components: Other Affects Versions: 1.2.10 Environment: .NET 3.5 SP1 Reporter: Matthew Gabeler-Lee Fix For: 1.2.11 FormatXml calls WriteStartElement using prefixed element names (e.g. log4net:event), but it calls the overload of WriteStartElement that expects a local name. Thus, if it writes to an xml writer that actually checks such things, it crashes. Instead, it should call the overload that separates the prefix from the local name. E.g.: writer.WriteStartElement(this.m_prefix, this.m_elmEvent, null). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-213) Problem while executing 2 windev applications
[
https://issues.apache.org/jira/browse/LOG4NET-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-213.
Resolution: Not A Problem
The file you are writing to is locked by the first process.
See
http://logging.apache.org/log4net/release/faq.html#How%20do%20I%20get%20multiple%20process%20to%20log%20to%20the%20same%20file?
Problem while executing 2 windev applications
-
Key: LOG4NET-213
URL: https://issues.apache.org/jira/browse/LOG4NET-213
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows XP
Reporter: Xavier Gosset
I'm using log4net in .NET for a long time. It's a wonderfull product.
I'm working now on Windev applications.
These applications are using .NET objects without any problems.
So, my idea was to use log4net in these applications.
So, I encapsulated my needs in another .NET assembly:
public class WDLogger
{
private StreamWriter _writer;
private ILog _logger = null;
public WDLogger()
{
}
public void Load(string loggerName)
{
// For internal debug
_writer = new System.IO.StreamWriter(c:\\ + loggerName +
_l4n.txt, true);
_writer.AutoFlush = true;
System.Console.SetOut(_writer);
FileInfo fileInfo = new FileInfo(log4net.config);
log4net.Config.XmlConfigurator.Configure(fileInfo);
_logger = LogManager.GetLogger(loggerName);
}
public void TraceDebug(string message)
{
if (_logger != null _logger.IsDebugEnabled)
_logger.Debug(message);
}
public void TraceInfo(string message)
{
if (_logger != null _logger.IsInfoEnabled)
_logger.Info(message);
}
public void TraceWarn(string message)
{
if (_logger != null _logger.IsWarnEnabled)
_logger.Warn(message);
}
public void TraceError(string message)
{
if (_logger != null _logger.IsErrorEnabled)
_logger.Error(message);
}
public void TraceFatal(string message)
{
if (_logger != null _logger.IsFatalEnabled)
_logger.Fatal(message);
}
}
I have two applications, A and B.
When I start the application A, the traces are written successfully.
When I start the application B, traces of this are not written.
I stop the two applications.
If I start application B, the traces are written successfully.
If I start application A after, traces of this are not written.
I activated log4net internal debug.
And there is only one difference.
Here is the log of application started first:
...
log4net: FileAppender: Opening file for writing
[E:\temp\testlogging\Exe\Logging\NaomiServerLog.txt] append [True]
log4net: XmlHierarchyConfigurator: Created Appender
[NaomiServerRollingFileAppender]
log4net: XmlHierarchyConfigurator: Adding appender named
[NaomiServerRollingFileAppender] to logger [NaomiServer].
log4net: XmlHierarchyConfigurator: Hierarchy Threshold []
INFO (2009-04-23 15:36:26,250 - toto) [Info1]
INFO (2009-04-23 15:36:26,265 - toto) [Info2]
Here is the log of the second application:
...
log4net: FileAppender: Opening file for writing
[E:\temp\testlogging\Exe\Logging\NaomiServerLog.txt] append [True]
log4net: XmlHierarchyConfigurator: Created Appender
[NaomiServerRollingFileAppender]
log4net: XmlHierarchyConfigurator: Adding appender named
[NaomiServerRollingFileAppender] to logger [NaomiServer].
log4net: XmlHierarchyConfigurator: Hierarchy Threshold []
log4net: FileAppender: Opening file for writing
[E:\temp\testlogging\Exe\Logging\ListenerLog.txt] append [True]
log4net: FileAppender: Opening file for writing
[E:\temp\testlogging\Exe\Logging\ListenerLog.txt] append [True]
Do you have an idea of what it could be?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-217) Delayed log
[
https://issues.apache.org/jira/browse/LOG4NET-217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-217:
---
Affects Version/s: (was: 1.2.11)
1.2.10
Fix Version/s: 3.5
Delayed log
---
Key: LOG4NET-217
URL: https://issues.apache.org/jira/browse/LOG4NET-217
Project: Log4net
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.10
Reporter: Fabio Maulo
Priority: Minor
Fix For: 3.5
would be useful an override like this
ILog.Debug(Funcstring messageDelegate);
callable as
log..Debug(()= MyTimeExpensiveMethod);
This is to prevent boiled code as
if(log.IsDebugEnable)
{
log..Debug(MyTimeExpensiveMethod());
}
Log4Net can call the messageDelegate only when really needed.
If you want stay in NET2.0 you can create a specific delegate
public delegate string MessageDelegate;
Btw, IMO, the new version should target directly .NET3.5.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-219) RollingFileAppender with varying dynamic filenames not working
[
https://issues.apache.org/jira/browse/LOG4NET-219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-219:
---
Fix Version/s: 1.2 Maintenance Release
RollingFileAppender with varying dynamic filenames not working
--
Key: LOG4NET-219
URL: https://issues.apache.org/jira/browse/LOG4NET-219
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: OS: Windows Server 2003, Sharepoint 2007
Reporter: Amar G
Fix For: 1.2 Maintenance Release
Attachments: log4netinternaldebug.txt
The Log4Net configuration file is as below:
log4net
appender name=RollingFile
type=log4net.Appender.RollingFileAppender
file type=log4net.Util.PatternString
value=C:\ErrorLog\%property{LogPath}/file
appendToFile value=true/appendToFile
maximumFileSize value=1024KB/maximumFileSize
maxSizeRollBackups value=2/maxSizeRollBackups
layout type=log4net.Layout.PatternLayout
conversionpattern value=%newline%date -
%message%newline/conversionpattern
/layout
/appender
logger name=File
level value=All /
appender-ref ref=RollingFile /
/logger
/log4net
In my application the debug method for logging the information will be called
many times. Some messages should get stored in a file with name say xy.log
and some messages should get stored in a file with name say ab.log.
In Global.asax i have written the following code:
log4net.Config.XmlConfigurator.ConfigureAndWatch(new
System.IO.FileInfo(Server.MapPath(/Log4Net.config)));
The above LOC is written in the Application_Start event
Actual call to the debug method:
log4net.GlobalContext.Properties[LogPath] =
String.Concat(FilePrefix,_Debug.log);
log4net.ILog filelogger = log4net.LogManager.GetLogger(File);
filelogger.Debug(info);
Issue: Although the property named LogPath is getting set properly, i dont
see any file with the name specified through the code getting created in the
path specified.
Can you please look into this and let me know whether i am missing something
or whether it is not supported?
Thanks in advance.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-220) multiple users overwrite existing log file when RollingFileAppender is rolling over date
[ https://issues.apache.org/jira/browse/LOG4NET-220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-220: --- Fix Version/s: 1.2 Maintenance Release multiple users overwrite existing log file when RollingFileAppender is rolling over date Key: LOG4NET-220 URL: https://issues.apache.org/jira/browse/LOG4NET-220 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: .net client side application running on framework 3.5 service pack 1, windows xp box makes use of log4net dll to write user info to log files Reporter: shabhana rampersadh Priority: Critical Fix For: 1.2 Maintenance Release config settings for rolling file appender ?xml version=1.0 encoding=utf-8 ? log4net debug=false appender name=RollingFileAppender type=log4net.Appender.RollingFileAppender,log4net param name=File value=C:\\Projects\\DealerMailer\\DealerMailer.UI\\DealerMailer.UI\\Log\\DealerMailer.UI_ / param name=RollingStyle value=Date / param name=DatePattern value=ddMM.lo\g / param name=StaticLogFileName value=false / param name=AppendToFile value=true / encoding value=utf-8 / param name=ImmediateFlush value=true / param name=LockingModel type=log4net.Appender.FileAppender+MinimalLock / layout type=log4net.Layout.PatternLayout,log4net param name=ConversionPattern value=%d [%-5level] [%logger] - %m%n / /layout /appender logger name=DealerMailerUI priority value=ALL / appender-ref ref=RollingFileAppender / /logger /log4net problem today 070702009 user1 logs into application today -- logs data in log file dated today (DealerMailer.UI_07072009.log) user2 logs into application today -- logs data in log file dated today (DealerMailer.UI_07072009.log) user2 logs out of application today -- logs data in log file dated today (DealerMailer.UI_07072009.log) tomorrow 08072009 user1 still has his application open from yesterday (all calls are per call basis so no locks are held) user2 logs into application -- no file exists, rolls over to next day logs data (DealerMailer.UI_08072009.log) user1 submits a transaction -- all data in (DealerMailer.UI_08072009.log) is overwritten i have no idea why this is happening -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-222) [PATCH] Improve AnsiColorTerminalAppender to support marking colors as Light
[ https://issues.apache.org/jira/browse/LOG4NET-222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-222: --- Fix Version/s: 1.2 Maintenance Release [PATCH] Improve AnsiColorTerminalAppender to support marking colors as Light Key: LOG4NET-222 URL: https://issues.apache.org/jira/browse/LOG4NET-222 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.10 Environment: Tested on Ubuntu Karmic, with log4net 1.2.10, should work on all Unix environments that speak VT100. Reporter: Bojan Priority: Trivial Fix For: 1.2 Maintenance Release The attached patch adds the ability to mark AnsiColors as Light using AnsiAttribute. This fixes a minor glitch in AnsiColorTerminalAppender that would cause AnsiColorTerminalAppender to output a grey-ish color instead of white when BackColor was set to AnsiColor.White by allowing the user to set the proper option of AnsiAttribute.Light and AnsiColor.White, rather than setting BackColor manually to 67 (60 for the light adjustment, 7 for white), and allows more color expressivity. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-223) [PATCH] Improve AnsiColorTerminalAppender to support marking colors as Light
[ https://issues.apache.org/jira/browse/LOG4NET-223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-223: --- Fix Version/s: 1.2 Maintenance Release [PATCH] Improve AnsiColorTerminalAppender to support marking colors as Light Key: LOG4NET-223 URL: https://issues.apache.org/jira/browse/LOG4NET-223 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.10 Environment: Tested on Ubuntu Karmic, with log4net 1.2.10, should work on all Unix environments that speak VT100. Reporter: Bojan Priority: Trivial Fix For: 1.2 Maintenance Release Attachments: light-adjustment.patch The attached patch adds the ability to mark AnsiColors as Light using AnsiAttribute. This fixes a minor glitch in AnsiColorTerminalAppender that would cause AnsiColorTerminalAppender to output a grey-ish color instead of white when BackColor was set to AnsiColor.White by allowing the user to set the proper option of AnsiAttribute.Light and AnsiColor.White, rather than setting BackColor manually to 67 (60 for the light adjustment, 7 for white), and allows more color expressivity. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-224) After implementing Log4net the application works fine but cannot see the log file created
[
https://issues.apache.org/jira/browse/LOG4NET-224?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-224:
---
Fix Version/s: 1.2 Maintenance Release
After implementing Log4net the application works fine but cannot see the log
file created
-
Key: LOG4NET-224
URL: https://issues.apache.org/jira/browse/LOG4NET-224
Project: Log4net
Issue Type: Task
Environment: Windows Server 2003, .NET 3.5
Reporter: Amit Viraktamath
Fix For: 1.2 Maintenance Release
Hi,
I have created a wrapper to the Log4net and used in my SharePoint webpart. I
am developing in .NET 3.5 framework on windows server 2003 platform. After I
deploy my webpart the web part works fine. however the logfine is not seen at
the configured path. Also there are no errors in the event viewer. Could you
please review the following code and suggest what is missing?
WEB.CONFIG file entries
configSections
section name=log4net
type=log4net.Config.Log4NetConfigurationSectionHandler,log4net-net-1.0/
/configSections
log4net
logger name=Log4netLoggingFramework
level value=INFO/
/logger
root
level value=INFO /
appender-ref ref=LogFileAppender /
appender-ref ref=ConsoleAppender /
/root
appender name=LogFileAppender
type=log4net.Appender.FileAppender
param name=File
value=C:\Inetpub\wwwroot\wss\VirtualDirectories\31569\logfile.log /
param name=AppendToFile value=true /
layout type=log4net.Layout.PatternLayout
param name=Header value=[Header]\r\n/
param name=Footer value=[Footer]\r\n/
param name=ConversionPattern value=%d [%t] %-5p %c
[%x]lt;%X{auth}gt; - %m%n/
/layout
filter type=log4net.Filter.LevelRangeFilter
param name=LevelMin value=INFO /
param name=LevelMax value=WARN /
/filter
/appender
appender name=ConsoleAppender
type=log4net.Appender.ConsoleAppender
layout type=log4net.Layout.PatternLayout
param name=ConversionPattern value=%d [%t] %-5p %c [%x]
lt;%X{auth}gt; - %m%n /
/layout
/appender
/log4net
Following is the C# code that wraps the requests to Log4net dll
--- CODE START --
namespace Log4netLoggingFramework
{
public static class LogInfo
{
public enum LogType { Debug = 1, Error = 2, Info = 3, Fatal = 4};
public static void Log(string logMessage, int logType)
{
//if (logType == LogType.Debug)
//{
//DebugLog dlog = new DebugLog();
//dlog.DoLogging(logMessage);
//}
//else if (logType == LogType.Info)
//{
//InfoLog ilog = new InfoLog();
//ilog.DoLogging(logMessage);
//}
//else if (logType == LogType.Error)
//{
//ErrorLog elog = new ErrorLog();
//elog.DoLogging(logMessage);
//}
if (logType == 1)
{
DebugLog dlog = new DebugLog();
dlog.DoLogging(logMessage);
}
else if (logType == 2)
{
InfoLog ilog = new InfoLog();
ilog.DoLogging(logMessage);
}
else if (logType == 3)
{
ErrorLog elog = new ErrorLog();
elog.DoLogging(logMessage);
}
}
}
public class DebugLog
{
private static readonly ILog logger =
LogManager.GetLogger(typeof(DebugLog));
/// summary
/// Constructor for the DebugLog
/// /summary
static DebugLog()
{
XmlConfigurator.Configure();
}
/// summary
/// Logs the Info
/// /summary
/// param name=loginfo/param
public void DoLogging(string loginfo)
{
if (logger.IsDebugEnabled)
{
logger.Debug(loginfo);
}
}
}
public class InfoLog
{
private static readonly ILog logger =
LogManager.GetLogger(typeof(InfoLog));
/// summary
/// InfoLog Constructor
/// /summary
static InfoLog()
{
XmlConfigurator.Configure();
}
/// summary
/// Logs the Info Log
/// /summary
/// param name=logInfo/param
public void DoLogging(string logInfo)
{
if (logger.IsInfoEnabled)
{
logger.Info(logInfo);
}
}
}
public class ErrorLog
{
[jira] [Updated] (LOG4NET-228) log4net.Util.HostName may throw System.Configuration.ConfigurationErrorsException in System.Net.Dns.GetHostName(). The exception should be ignored.
[ https://issues.apache.org/jira/browse/LOG4NET-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-228: --- Fix Version/s: 1.2 Maintenance Release What are the circumstances that make Dns.GetHostName throw a ConfigurationException? The docs don't say it could do so. log4net.Util.HostName may throw System.Configuration.ConfigurationErrorsException in System.Net.Dns.GetHostName(). The exception should be ignored. --- Key: LOG4NET-228 URL: https://issues.apache.org/jira/browse/LOG4NET-228 Project: Log4net Issue Type: Bug Reporter: Igor Buchelnikov Fix For: 1.2 Maintenance Release -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-234) RollingFileAppender generates incorrect file name
[ https://issues.apache.org/jira/browse/LOG4NET-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-234: --- Fix Version/s: 1.2 Maintenance Release RollingFileAppender generates incorrect file name - Key: LOG4NET-234 URL: https://issues.apache.org/jira/browse/LOG4NET-234 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows XP, Windows 2003 Reporter: Miroslav Vanicky Fix For: 1.2 Maintenance Release Attachments: logs.zip Original Estimate: 24h Remaining Estimate: 24h I have Appender defined as follow... appender name=RollingFileAppender type=log4net.Appender.RollingFileAppender file value=Logs\Log / !-- Základní název souboru -- appendtofile value=true / rollingstyle value=Date / !-- Soubory budou vznikat na základě datumu/času logu -- datepattern value=_-MM-dd.\tx\t/ !-- Maska pro název souboru (to .\tx\t tam musí být, aby byla přípona .txt)-- StaticLogFileName value=false / !-- Už první vzniklý soubor bude mít název obsahující datum. Jinak by logoval stále do jednoho stejného souboru a ten by v případě potřeby (změna datumu) přejmenoval -- !-- Co a jak bude formátováno ve výstupu. Seznam všech dostupných %proměnných je na: http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html Na stejné stránce dole je popsáno i co znamená to -5level apod. -- layout type=log4net.Layout.PatternLayout conversionpattern value=%date [%-5level] - %message%newline/conversionpattern /layout /appender This Appender should generate file names like Log_2009-10-15.txt, mostly it works fine, but in some unknown situations it generates file named Log_2009-10-15.txt_2009-10-15.txt. It seems to me that this happens when there were no log-files and the incorrectly named file was the first log-file generated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-238) Release date for Log4net version 1.2.11...
[ https://issues.apache.org/jira/browse/LOG4NET-238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-238. Resolution: Invalid In general we don't promise any release dates - in this particular case 1.2.11 is certainly well overdue. At this point in time I can assure you we are working on getting the release out soon, but still I won't give any date. Release date for Log4net version 1.2.11... -- Key: LOG4NET-238 URL: https://issues.apache.org/jira/browse/LOG4NET-238 Project: Log4net Issue Type: Improvement Reporter: Paul Freeman Original Estimate: 2m Remaining Estimate: 2m Hiya, I have not been able to find out when the expected release date is scheduled for and it would be nice if this information was available... even if it was just to say that there are no plans to release the next version in the next 6 months, etc. I have searched the web and found a couple of people asking this question but with no replies. Hence, I thought this would be the best place to find out this information... apologies if this question should be posted elsewhere. In my particular case I would like to preserve the log file extensions, which according to the forum has been fixed in 1.2.11. I would like to get an idea of when this is likely to be released... shortly, months, years, etc. I don't want to patch my current version as I can live without it for the time being, but I need to find out when this is likely to be released... so I can provide feedback to others on when this new version is available. Apologies again if this question is misplaced, but I would be very grateful if someone could just give me an idea of the release date... or if I am just not looking in the right place, forward me to the relevant place. Thanks very much in advance for your help! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-241) Issue tracking page does not link to project
[ https://issues.apache.org/jira/browse/LOG4NET-241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-241: --- Fix Version/s: 1.2.11 Issue tracking page does not link to project Key: LOG4NET-241 URL: https://issues.apache.org/jira/browse/LOG4NET-241 Project: Log4net Issue Type: Bug Components: Documentation Environment: http://logging.apache.org/log4net/issue-tracking.html Reporter: Sebb Fix For: 1.2.11 The issue tracking page http://logging.apache.org/log4net/issue-tracking.html links to http://issues.apache.org/jira/ which is not particularly helpful. It should link to http://issues.apache.org/jira/browse/LOG4NET or https://issues.apache.org/jira/browse/LOG4NET -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-243) broken link on http://logging.apache.org/log4net/release/example-apps.html
[ https://issues.apache.org/jira/browse/LOG4NET-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-243: --- Fix Version/s: 1.2.11 broken link on http://logging.apache.org/log4net/release/example-apps.html -- Key: LOG4NET-243 URL: https://issues.apache.org/jira/browse/LOG4NET-243 Project: Log4net Issue Type: Bug Components: Documentation Environment: web browser Reporter: Daniel Schobel Priority: Minor Fix For: 1.2.11 Original Estimate: 0.5h Remaining Estimate: 0.5h the link in the text: The following examples are only available in the log4net release download, not on-line. To obtain the examples download one of the log4net releases. in the Overview section points to http://logging.apache.org/log4net/downloads.html whereas it should point to http://logging.apache.org/log4net/download.html . The current link yields a 404. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-242) Download page does not have link to KEYS file
[ https://issues.apache.org/jira/browse/LOG4NET-242?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-242: --- Fix Version/s: 1.2.11 Download page does not have link to KEYS file - Key: LOG4NET-242 URL: https://issues.apache.org/jira/browse/LOG4NET-242 Project: Log4net Issue Type: Bug Components: Documentation Environment: http://logging.apache.org/log4net/download.html Reporter: Sebb Priority: Critical Fix For: 1.2.11 The download page http://logging.apache.org/log4net/download.html has a link describing why one should verify releases, but fails to provide a link to the relevant KEYS file -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-244) SmtpAppender.To Property has incorrect delimiter
[ https://issues.apache.org/jira/browse/LOG4NET-244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-244: --- Fix Version/s: 1.2.11 SmtpAppender.To Property has incorrect delimiter Key: LOG4NET-244 URL: https://issues.apache.org/jira/browse/LOG4NET-244 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Win 2003 Server Running ASP.net application on framework 2.0 Reporter: Charles Chatt Fix For: 1.2.11 SmtpAppender.To Property has an incorrect delimiter listed in the documentation. When the semicolon delimiter is used (per spec) the application will not send emails to the list. Yet, if the delimiter is changed to a comma, everything works fine. Here is the link to the documentation which specifies the semicolon delimiter. http://logging.apache.org/log4net/release/sdk/log4net.Appender.SmtpAppender.To.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-245) Need information on Exception Handling mechanism used in Log4Net project
[ https://issues.apache.org/jira/browse/LOG4NET-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-245. Resolution: Invalid This really is a question that should be asked on one of the mailing lists and not raised as an issue. Anyway: $ find . -name \*.cs | xargs -e fgrep Unhand ./src/Core/DefaultRepositorySelector.cs: LogLog.Error(declaringType, Unhandled exception in GetInfoForAssembly, ex); This is the only place in the source tree witth the test Unhand in it. Need information on Exception Handling mechanism used in Log4Net project - Key: LOG4NET-245 URL: https://issues.apache.org/jira/browse/LOG4NET-245 Project: Log4net Issue Type: Task Affects Versions: 1.2.10 Environment: XP Reporter: Rajat Raina Priority: Blocker Labels: Error, Handling I need some information as we are working on a common Exception handling framework for all our code. Can you please let me know if Log4Net dll defines any Exception filters through the usage of Microsoft's SetUnhandledExceptionFilter? I need this information for my common exception handling framework designing. Please let me know! Thanks! -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-246) Make it possible to choose whether or not to watch configuration files specified using the log4net.Config appsetting key
[ https://issues.apache.org/jira/browse/LOG4NET-246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-246: --- Fix Version/s: 1.2.11 Your patch is the wrong way around (you've mixed up old and new) but otherwise looks OK to me. Make it possible to choose whether or not to watch configuration files specified using the log4net.Config appsetting key --- Key: LOG4NET-246 URL: https://issues.apache.org/jira/browse/LOG4NET-246 Project: Log4net Issue Type: Improvement Components: Core Affects Versions: 1.2.10 Reporter: Uri Goldstein Priority: Minor Labels: appsettings, configuration Fix For: 1.2.11 Attachments: DefaultRepositorySelector-LOG4NET-246-PatchA.patch Currently (v1.2.10) it is possible to specify a configuration file for log4net by adding a key like this in the host application's configuration appSettings section: add key=log4net.Config value=Log.config / This defaults to invoking XmlConfigurator.Configure() on the file specified (log4net/Core/DefaultRepositorySelector.cs, line 725). This means the file is not watched for changes during program run time. It would be nice if there was some way similar to the above appSettings key to specify whether log4net should watch the file or not. I might propose that a new key is introduced in this fashion: add key=log4net.Config.Watch value=true / This key would denote a bool value defaulting to false. The value would only be taken into consideration if the log4net.Config key is specified. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-249) Please make RollFile virtual so that we can enhance rolling strategies
[ https://issues.apache.org/jira/browse/LOG4NET-249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-249: --- Fix Version/s: 1.2 Maintenance Release Please make RollFile virtual so that we can enhance rolling strategies Key: LOG4NET-249 URL: https://issues.apache.org/jira/browse/LOG4NET-249 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.10 Environment: All Reporter: Scott Mitchell Labels: method, virtual Fix For: 1.2 Maintenance Release Original Estimate: 1h Remaining Estimate: 1h I enhanced the RollingFileAppender so that you can roll to S3 (I call it RollingS3FileAppender). Right now, I have to duplicate all of the RollingFileAppender code because the RollFile method is not virtual. Can this be worked into the next build? NOTE: After trying to work with the RollingFileAppender, I decided that it would be cleaner to just write an S2Appender based on the AppenderSkeleton. Source code is available here: http://s3appender.codeplex.com/ -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-297) AppenderSkeleton.RequiresLayout docs and implementation don't match
[
https://issues.apache.org/jira/browse/LOG4NET-297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-297:
---
Component/s: (was: Appenders)
Documentation
Fix Version/s: 1.2.11
AppenderSkeleton.RequiresLayout docs and implementation don't match
---
Key: LOG4NET-297
URL: https://issues.apache.org/jira/browse/LOG4NET-297
Project: Log4net
Issue Type: Bug
Components: Documentation
Affects Versions: 1.2.10
Reporter: Chris Dolan
Priority: Minor
Fix For: 1.2.11
In AppenderSkeleton.cs:
/// para
/// This default implementation always returns ctrue/c.
/// /para
virtual protected bool RequiresLayout
{
get { return false; }
}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-273) AdoNetAppender does not work if you dont copy System.Data.dll
[
https://issues.apache.org/jira/browse/LOG4NET-273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-273:
---
Fix Version/s: 1.2 Maintenance Release
AdoNetAppender does not work if you dont copy System.Data.dll
-
Key: LOG4NET-273
URL: https://issues.apache.org/jira/browse/LOG4NET-273
Project: Log4net
Issue Type: Bug
Affects Versions: 1.2.10
Environment: Windows 7, .Net 2.0
Reporter: Evald
Fix For: 1.2 Maintenance Release
AdoNetAppender does not work if you dont copy System.Data.dll
log4net writes at output this line: log4net:ERROR [AdoNetAppender] Failed to
load connection type [System.Data.SqlClient.SqlConnection, System.Data]
if you copy the dll than it begin working.
here it is my config:
appender name=SQLAppender type=log4net.Appender.AdoNetAppender
bufferSize value=1 /
connectionType value=System.Data.SqlClient.SqlConnection,
System.Data /
connectionString value=Data Source=localhost;initial
catalog=testlog4net;integrated security=false;User ID=sa;Password=mypassword
/
commandText value=INSERT INTO testlog4net.dbo.Log
([Date],[Thread],[LevelName],[Logger],[Message]) VALUES (@log_date, @thread,
@log_level, @logger, @message) /
parameter
parameterName value=@log_date /
dbType value=Datetime /
layout type=log4net.Layout.PatternLayout
value=%date{'-'MM'-'dd HH':'mm':'ss'.'fff} /
/parameter
parameter
parameterName value=@thread /
dbType value=String /
size value=255 /
layout type=log4net.Layout.PatternLayout value=%thread /
/parameter
parameter
parameterName value=@log_level /
dbType value=String /
size value=50 /
layout type=log4net.Layout.PatternLayout value=%level /
/parameter
parameter
parameterName value=@logger /
dbType value=String /
size value=255 /
layout type=log4net.Layout.PatternLayout value=%logger /
/parameter
parameter
parameterName value=@message /
dbType value=String /
size value=4000 /
layout type=log4net.Layout.PatternLayout value=%message /
/parameter
/appender
Thank you
Regards
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-282) Database Risk and PCI Compliance with ado.net appender
[ https://issues.apache.org/jira/browse/LOG4NET-282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-282: --- Fix Version/s: 1.2 Maintenance Release Database Risk and PCI Compliance with ado.net appender -- Key: LOG4NET-282 URL: https://issues.apache.org/jira/browse/LOG4NET-282 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.9, 1.2.10 Reporter: Tim Schwallie Labels: security Fix For: 1.2 Maintenance Release Per our PCI/Risk exposure reviewer, the ado.net appender in log4net is a risk. Essentially, if somebody can gain access to the config file, they can change the config file to run any query via an error. Obviously, there's a bigger concern if somebody can change a config file. The reviewer felt that with log4net being a popular tool this was a high risk cause of how easy it would be for an attacker to change it. Other logging tools make a call to a hard-coded stored procedure to log to a database. If the ado.net appender could be changed to call a fixed stored procedure and perhaps pass parameters with some fixed and maybe a concatenated string for a variable number of parameters, the risk would probably be removed. The SP would be responsible with working with the concatenated string. A formatter may be the way to go to make the concatenated string. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-204) Silverlight compiled binary
[ https://issues.apache.org/jira/browse/LOG4NET-204?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13097883#comment-13097883 ] Arjan Veenstra commented on LOG4NET-204: Silverlight supports only a subset of .NET and is binary incompatible, which is quite a PITA. Microsoft made some seemingly random (I'm sure there are reason, but often I can't find them) decisions about what is supported in Silverlight. On top of that some stuff actually changed, e.g. lots of classes are suddenly sealed, non-generic collections are made internal etc. As a quick check I converted the log4net project file to Silverlight and tried to build it, which resulted in quite a few errors. At least there are the following issues: - Serialization needs to use DataContract, not Serializable. - All collections need to become generic. - XML parsing needs to be done useing Linq2XML as XmlDocument/XmlElement etc are not available. - Some appenders depend on stuff unavailable in Silverlight (they could be disabled though). - Lots of appenders will only work when elevated trust is available. I also guess some of the required changes might break conflict with compatibility with older .NET versions. I'd really like to have Log4Net available on Silverlight, but getting there won't be a trivial task. Silverlight compiled binary --- Key: LOG4NET-204 URL: https://issues.apache.org/jira/browse/LOG4NET-204 Project: Log4net Issue Type: Wish Components: Builds, Examples Affects Versions: 1.2.10 Reporter: Trond Andersen Fix For: 1.2 Maintenance Release There should be a Silverlight build of log4net that can be used in Silverlight applications. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-279) Disabling Log4net
[ https://issues.apache.org/jira/browse/LOG4NET-279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-279. Resolution: Invalid Really a user-list question rather than an issue tracker ticket. Ron has answered this. Disabling Log4net -- Key: LOG4NET-279 URL: https://issues.apache.org/jira/browse/LOG4NET-279 Project: Log4net Issue Type: Bug Environment: .Net Framework 3.0, C#, Windows XP SP3 Reporter: Dark Flare Priority: Critical Original Estimate: 0h Remaining Estimate: 0h Hi, I am currently writing a large project which involves using a Large library (Dlls) which allow me to use, show and manipulate map files (mainly tiff). I have no access to the dlls source code. The dll creates logs using log4net (as i see the log4net dll bundled with it). The logs which are being created are quite large, mainly around 7mbs per txt file. I do not wish to create the logs, since they are in the external dll only, i have my own dll module which i use in my Application. I wish to completely disable log4net, i dont want it to create any logs whatsoever. I read about changing xml files and whatnot but i do not have this xml file in the application, I tried creating it and changed stuff like setting the threshold =OFF. but the logs are still being created. Is there another way to disable the logs completely ? thx -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-294) Exception rendering object type [System.OutOfMemoryException]
[
https://issues.apache.org/jira/browse/LOG4NET-294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-294:
---
Fix Version/s: 1.2 Maintenance Release
Exception rendering object type [System.OutOfMemoryException]
-
Key: LOG4NET-294
URL: https://issues.apache.org/jira/browse/LOG4NET-294
Project: Log4net
Issue Type: Bug
Affects Versions: 1.2.10
Environment: window2003 server, .Net framework 3.5. incorporated into
Microsoft MOSS 2007Platform.
Reporter: xiaofeng chen
Fix For: 1.2 Maintenance Release
configuration:
?xml version=1.0 encoding=utf-8?
log4net
appender name=FatalFile type=log4net.Appender.RollingFileAppender
file value=Log directory /
appendToFile value=true /
rollingStyle value=Date /
maximumFileSize value=10240KB /
StaticLogFileName value=false /
maxSizeRollBackups value=10 /
datePattern value=.-MM-ddquot;.logquot; /
layout type=log4net.Layout.PatternLayout
conversionPattern value=time:%date threadID:[%thread] level:%-5level
class:%logger property:[%property{NDC}] - decription:%message%newline /
/layout
/appender
logger name=DEBUGGER additivity=false
level value=ALL /
/logger
root
level value=FATAL /
appender-ref ref=FatalFile /
/root
/log4net
Error Stack:
log4net.ErrorException rendering object type
[System.OutOfMemoryException]stackTraceSystem.OutOfMemoryException:
Exception of type 'System.OutOfMemoryException' was thrown.
at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap
rendererMap, Object obj, TextWriter writer)
at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter
writer)/stackTrace/log4net.Error
Note:
This error doesn't always shows. We're not sure what effect will push on our
application by this issue. We also notice that some one report this issue
here:https://issues.apache.org/jira/browse/LOG4NET-192
But the resolution said 'Cannot Reproduce'. Now, ii reproduced again.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-253) GetLogger creates rolling files even for the unreferenced files
[ https://issues.apache.org/jira/browse/LOG4NET-253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-253: --- Fix Version/s: 1.2 Maintenance Release GetLogger creates rolling files even for the unreferenced files --- Key: LOG4NET-253 URL: https://issues.apache.org/jira/browse/LOG4NET-253 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows XP Reporter: Yves Bastiand Fix For: 1.2 Maintenance Release Hi, I have a C# solution that contains three executables. I have each of these three executables sharing the same log4net configuration file. At startup of each of the executable, they retrieve a logger (one logger per executable, as per configuration file further below). When one of the executable performs Log.GetLogger(loggerName), it creates all the rolling files instead of only the one rolling file that is referred to as appender-ref in the executable's logger configuration. For instance, when I startup my sending daemon executable, it performs Log.GetLogger(SendingDaemonLogger) which creates 3 files Log/RuleScheduler.txt, Log/NotificationGenerator.txt and Log/NotificationSender.txt instead of only the desired Log/NotificationSender.txt. Then when I startup another of the executables, for instance the rule scheduler daemon, this other process cannot write in Log/RuleScheduler.txt because it has been created and locked by the sending daemon process. I am guessing that there may be three different solutions to my problem: 1. The GetLogger should only create the rolling file appenders that are referenced in the config 2. I should have one config file per executable, this way each config file could list only one rolling file appender and starting each of the executable would not create the rolling files of the other daemons. I am however reluctant to do this because some of the configuration (SMTP appender, console appender) is shared between the daemons and I don't want to have duplicate copies to maintain. Unless there is a way to have a config file including another one? 3. Maybe there is a way to configure the rolling file so that concurrent access across processes is allowed? This solution still isn't perfect in my opinion because any of the daemons should not be creating the rolling files of some other daemons. Thanks in advance for your help! My configuration file is below: ?xml version=1.0 encoding=utf-8 ? log4net appender name=RuleSchedulerFileAppender type=log4net.Appender.RollingFileAppender file value=Log/RuleScheduler.txt/ threshold value=INFO/ appendToFile value=true/ !-- For each month, keep up to 100 files of 10Mb within the month-- rollingStyle value=Composite / datePattern value=MM / maxSizeRollBackups value=100 / maximumFileSize value=10MB / !-- The latest log file has the greatest number -- countDirection value=1 / layout type=log4net.Layout.PatternLayout conversionPattern value=%ndc [%thread] %date %-4timestamp %-5level %message (%method(), L%line %class) %newline%exception/ /layout /appender appender name=NotificationGeneratorFileAppender type=log4net.Appender.RollingFileAppender file value=Log/NotificationGenerator.txt/ threshold value=INFO/ appendToFile value=true/ !-- For each month, keep up to 100 files of 10Mb within the month-- rollingStyle value=Composite / datePattern value=MM / maxSizeRollBackups value=100 / maximumFileSize value=10MB / !-- The latest log file has the greatest number -- countDirection value=1 / layout type=log4net.Layout.PatternLayout conversionPattern value=%ndc [%thread] %date %-4timestamp %-5level %message (%method(), L%line %class) %newline%exception/ /layout /appender appender name=NotificationSenderFileAppender type=log4net.Appender.RollingFileAppender file value=Log/NotificationSender.txt/ threshold value=INFO/ appendToFile value=true/ !-- For each month, keep up to 100 files of 10Mb within the month-- rollingStyle value=Composite / datePattern value=MM / maxSizeRollBackups value=100 / maximumFileSize value=10MB / !-- The latest log file has the greatest number -- countDirection value=1 / layout type=log4net.Layout.PatternLayout conversionPattern value=%ndc [%thread] %date %-4timestamp %-5level %message (%method(), L%line %class) %newline%exception/ /layout /appender appender name=DebugConsoleAppender type=log4net.Appender.ColoredConsoleAppender threshold value=ALL/ mapping level value=FATAL / foreColor value=White /
[jira] [Resolved] (LOG4NET-251) RollingFileAppender with rollingStyle=Date and maximumFileSize both are not working Simultaneously.
[ https://issues.apache.org/jira/browse/LOG4NET-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-251. Resolution: Invalid This really is a user-list question. In order to roll on date and size you must use Composite as rollingStyle. See the third example in http://logging.apache.org/log4net/release/config-examples.html#RollingFileAppender RollingFileAppender with rollingStyle=Date and maximumFileSize both are not working Simultaneously. --- Key: LOG4NET-251 URL: https://issues.apache.org/jira/browse/LOG4NET-251 Project: Log4net Issue Type: Bug Components: Appenders Environment: windows-7 OS Reporter: rakesh I have one problem with RollingFileAppender Type. when i am create a configuration with rollingstyle=Date and with maximumFileSize=1 KB. then also appender is write a more then 1 kb. of file size. now we remove a rollingstyle=Date then it works fine with maximumFileSize. is there are any problem with maximumFileSize and rollingstyle=Date ? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-252) RollingFileAppender stops logging intermittently when it tries to roll over the log file
[ https://issues.apache.org/jira/browse/LOG4NET-252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-252: --- Fix Version/s: 1.2 Maintenance Release RollingFileAppender stops logging intermittently when it tries to roll over the log file Key: LOG4NET-252 URL: https://issues.apache.org/jira/browse/LOG4NET-252 Project: Log4net Issue Type: Bug Components: Appenders Environment: log4net - 1.2.0.30714 Reporter: Kapil Goyal Priority: Critical Fix For: 1.2 Maintenance Release I tried to analyze the diagnostic log for log4net but did not find any ERRORs. I did notice that when the logging stopped working, the last statement in the diagnostic log indicated an attempt to roll-over. This issue was reproduced 3-4 times in the span of around 10 days. Restarting the process will cause the logging to start again. Below is the diagnostic log followed by the log4net configuration being used. Diagnostic Log -- log4net: FileAppender: Opening file for writing [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log] append [False] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.1] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.1] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.2] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.3] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.3] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.4] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.4] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.5] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.5] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.6] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.6] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.7] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.7] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.8] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.8] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.9] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.9] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.10] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.10] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.11] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.11] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.12] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.12] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.13] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.13] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.14] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.14] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.15] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.15] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.16] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.16] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.17] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.17] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.18] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.18] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.19] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.19] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.20] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.20] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.21] - [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.2010-03-22.21] log4net: RollingFileAppender: Moved [D:\Apps\Program Files\Ensim\Unify\eTraceLogs\PE.log.22] - [D:\Apps\Program
[jira] [Updated] (LOG4NET-254) [PATCH] Added Snmp V1 Trap Appender
[ https://issues.apache.org/jira/browse/LOG4NET-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-254: --- Fix Version/s: 1.2 Maintenance Release we won't be able to use your patch(es) unless you grant a license to the ASF [PATCH] Added Snmp V1 Trap Appender --- Key: LOG4NET-254 URL: https://issues.apache.org/jira/browse/LOG4NET-254 Project: Log4net Issue Type: New Feature Components: Appenders Environment: independent Reporter: Thomas Johnson Fix For: 1.2 Maintenance Release Attachments: SnmpTrapAppender.cs, SnmpTrapAppender.patch Original Estimate: 0h Remaining Estimate: 0h Added simple Snmp V1 Trap appender. Properties are based on configuration XML for log4j. I interpreted ApplicationTrapOID from the log4j appender to mean the ObjectOID for the message variable added to the TrapPDU. Uptime ticks PDU element based on time appender class is instantiated. Could be extended to include options for app pool uptime or time since last boot, etc. 4K character limit imposed on message length, extra cares will be truncated. Baseline revision: 881070 New File: apache-log4net\src\Appender\SnmpTrapAppender.cs Example Config: appender name=SnmpTrapAppender type=log4net.Appender.SnmpTrapAppender RemoteAddress value=127.0.0.1 / RemotePort value=162 / EnterpriseOID value=1.3.6.1.X.X.XXX.X.X / ApplicationTrapOID value=1.3.6.1.X.X.XXX.X.X.X.14 / CommunityString value=public / GenericTrapType value=EnterpriseSpecific / SpecificTrapType value=16 / layout type=log4net.Layout.PatternLayout conversionPattern value=%message / /layout /appender -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-257) Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory
[ https://issues.apache.org/jira/browse/LOG4NET-257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-257. Resolution: Duplicate Fix Version/s: 1.2.11 Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory -- Key: LOG4NET-257 URL: https://issues.apache.org/jira/browse/LOG4NET-257 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Visual Studio 2010 .NET 4.0 project on Windows XP Reporter: Jay Smith Fix For: 1.2.11 Original Estimate: 24h Remaining Estimate: 24h When adding a reference to a .NET 4.0 Console Application in Visual Studio 2010 the IDE does not recognize the library. After downloading the source I was able to get it work by updating all of the references to .NET 4.0 reference. The main one in question is the System.Web reference which I assume is there for the Asp .NET Trace appender. Are there plans for updating the library for use with .NET 4.0? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-256) log4net With MDC is not exactly threadsafe?
[ https://issues.apache.org/jira/browse/LOG4NET-256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-256: --- Fix Version/s: 1.2 Maintenance Release log4net With MDC is not exactly threadsafe? --- Key: LOG4NET-256 URL: https://issues.apache.org/jira/browse/LOG4NET-256 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows Server 2003, Windows XP Reporter: MK Pandey Fix For: 1.2 Maintenance Release Attachments: bug detals mail.jpg Hi All, Our situation is that we are using MDC values (ex, transID) to set additional values which is used across multiple classes to identify the transaction. We have one LogHelper class which creates private static instance of the as below: log4net.ILog fileLogger = LogManager.GetLogger(GetType()); When second thread starts and modifies the values, the subsequent logs from other threads start using the same values. Any suggestions? When using web.config file for appender defintion, is this not thread safe? -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-259) Log4Net does not create a new tab in Chainsaw
[ https://issues.apache.org/jira/browse/LOG4NET-259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-259: --- Fix Version/s: 1.2 Maintenance Release Log4Net does not create a new tab in Chainsaw - Key: LOG4NET-259 URL: https://issues.apache.org/jira/browse/LOG4NET-259 Project: Log4net Issue Type: Task Components: Documentation Affects Versions: 1.2.10 Reporter: David Mackersie Priority: Minor Fix For: 1.2 Maintenance Release I believe the problem is in XmlLayoutSchemaLog4j, and that you need to change log4japp to application. According to the Chainsaw tutorial: Chainsaw automatically looks inside each received LoggingEvent for a special Application property to determine which tab to route an event to. If it cannot find this property, it attempts to use a secondary property usually added via the SocketAppender or SocketHubAppender which identify the remote host of these events. If neither of these are found, Chainsaw routes events to a default Unknown tab. Logging events generated internally by chainsaw include the following properties: log4j:properties log4j:data name=application value=Generator 1/ log4j:data name=hostname value=localhost/ log4j:data name=log4jid value=2/ log4j:data name=some string value=some valueGenerator 1/ /log4j:properties Logging events generated by XmlLayoutSchemaLog4j include the following properties: log4j:properties log4j:data name=log4net:UserName value=DOMAIN\username/ log4j:data name=log4jid value=281/ log4j:data name=log4jmachinename value=machineName/ log4j:data name=log4net:HostName value=machineName/ log4j:data name=log4japp value=Application.exe/ /log4j:properties See also: http://www.mail-archive.com/log4j-dev@jakarta.apache.org/msg05361.html UPDATE: Documentation issue. See comments below. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-261) RemoteSyslogAppender doesn't work because of IPv6
[ https://issues.apache.org/jira/browse/LOG4NET-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-261: --- Fix Version/s: 1.2 Maintenance Release RemoteSyslogAppender doesn't work because of IPv6 - Key: LOG4NET-261 URL: https://issues.apache.org/jira/browse/LOG4NET-261 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows Seven x86_64 Visual Studio Team System unit test Reporter: Antonio Anzivino Fix For: 1.2 Maintenance Release Original Estimate: 3h Remaining Estimate: 3h I tried to make experiments with Log4net and Syslog appender for a research open source project I'm working. Tried to send the log messages to a local UDP listener using RemoteSyslogAppender. Logging code executed but on the debug console I got an exception: log4net:ERROR [RemoteSyslogAppender] Unable to send logging event to remote syslog fe80::8038:6515:ad7a:bdb5%15 on port 3434. System.Net.Sockets.SocketException: Indirizzo utilizzato incompatibile con il protocollo richiesto [Address used is incompatible with required protocol] in System.Net.Sockets.Socket.SendTo(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags, EndPoint remoteEP) in System.Net.Sockets.UdpClient.Send(Byte[] dgram, Int32 bytes, IPEndPoint endPoint) in log4net.Appender.RemoteSyslogAppender.Append(LoggingEvent loggingEvent) ALL: 2010-07-06 23:24:11,364 [Agent: adapter run thread for test 'TestMethod' with id 'f3dfe8eb-635a-4683-8777-a029f3897071'] ERROR ALL [(null)] - Test error message RemoteSyslogAppender is trying to send the message to an IPv6 address rather than 127.0.0.1 Precisely, if I configure remoteAddress as localhost, it tries to send to ::1, if I use 127.0.0.1 it tries to send to an IPv6 link-local address (fe80:...) Code can be found at https://logbus-ng.svn.sourceforge.net/viewvc/logbus-ng/trunk/logbus-core/Log4test/?pathrev=106 as a Visual Studio Unit Test. It is revision 106 of https://logbus-ng.svn.sourceforge.net/svnroot/logbus-ng/trunk/logbus-core/Log4test/ I tried to look at RemoteSyslogAppender implementation. I couldn't find a possible root cause because I can see you correctly initialize the UdpClient with parameterless constructor (UdpAppender::InitializeConnection()). The only way I could send datagrams was to use a FQDN as remoteAddress for which only A record is defined in the DNS. I also found that the RemoteSyslog appender doesn't respect RFC3164 by default unless you configure it with an appropriate pattern. I will open a new issue about it. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-262) Redesigning Syslog in Log4net
[ https://issues.apache.org/jira/browse/LOG4NET-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-262: --- Fix Version/s: 1.2 Maintenance Release Redesigning Syslog in Log4net - Key: LOG4NET-262 URL: https://issues.apache.org/jira/browse/LOG4NET-262 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.10 Environment: All Reporter: Antonio Anzivino Priority: Minor Fix For: 1.2 Maintenance Release Hello, I just want to sugges to apply the following modifications to Log4net (apply also to Log4j): *Create a SyslogLayout layout class that formats messages into Syslog format (both RFC3164 and RFC5424). Currently you have to search for a good PatternLayout that matches RFC specifications. Even if that could be, ultimately, inheriting from PatternLayout and setting a constant pattern... At least we have a valid layout in a class *RemoteSyslogAppender currently prepends the PriVal field to the regular message formatted accordingly with the pattern. SimpleLayout might not work properly. Suggesting to make RemoteSyslogAppender work only with properly implemented SyslogLayout[s] for both the RFCs Having a Syslog layout, especially for RFC5424 which is not only recent, but supports a full UTC timestamp complete with year (unsupported by RFC3164) is very useful when performing long-term log analysis and allows to store messages in Syslog format into files, almost like syslog-ng daemon does with /var/log/messages. I'm currently working on an open source logging framework (Logbus-ng) that does only log collection and broadcasting and *that we want to make fully compatible with Log4xxx*: our team has already implemented a fully working formatter for Syslog RFC5424 messages. If you need code, we can share it. I personally plan to implement these two features as classes external to Log4net, but I would like to suggest the Log4net dev team to do so before us because I feel the utility of such a work for the community. Thank you. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-263) add event before write to log to cancel or continue writing
[ https://issues.apache.org/jira/browse/LOG4NET-263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-263: --- Fix Version/s: 1.2 Maintenance Release add event before write to log to cancel or continue writing --- Key: LOG4NET-263 URL: https://issues.apache.org/jira/browse/LOG4NET-263 Project: Log4net Issue Type: New Feature Components: Core Environment: .net Reporter: caxey jones Fix For: 1.2 Maintenance Release I have thread application and when error will write to log file. And need checking if same message, I dont want to write again in certain interval maybe 10 seconds. I think the possibility is to add OnWriting feature on log4net so developer have control to cancel or continue writing add event before write to log to cancel or continue writing. so in event argument we can set like this e.Cancel = true; to cancel writing to log. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-264) Unexpected/Invalid(?) System.PlatformNotSupportedException
[ https://issues.apache.org/jira/browse/LOG4NET-264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-264: --- Fix Version/s: 1.2 Maintenance Release Any chance you still have the full stack trace around? Unexpected/Invalid(?) System.PlatformNotSupportedException -- Key: LOG4NET-264 URL: https://issues.apache.org/jira/browse/LOG4NET-264 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows XP SP3; .NET Framework 3.5 SP1 Reporter: Troy Walker Fix For: 1.2 Maintenance Release A user of my software that utilizes log4net is getting the following exception upon initializing log4net 1.2.10 despite the fact that the user is running Windows XP SP3 with the .NET Framework 3.5 SP1. System.TypeInitializationException: The type initializer for 'log4net.GlobalContext' threw an exception. --- System.PlatformNotSupportedException: This operation is only supported on Windows 2000 SP3 or later operating systems. at System.Security.Principal.SecurityIdentifier..ctor(WellKnownSidType sidType, SecurityIdentifier domainSid) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-265) RemoteFileAppender Tests fail on Windows 7
[ https://issues.apache.org/jira/browse/LOG4NET-265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-265: --- Affects Version/s: (was: 1.2.11) Fix Version/s: 1.2.11 RemoteFileAppender Tests fail on Windows 7 -- Key: LOG4NET-265 URL: https://issues.apache.org/jira/browse/LOG4NET-265 Project: Log4net Issue Type: Bug Components: Appenders Environment: Windows 7 32bit Reporter: Rob Prouse Priority: Minor Fix For: 1.2.11 Attachments: log4net-265.patch Original Estimate: 3h Remaining Estimate: 3h Compiled the version of log4net in the repository and ran the unit tests. All of the RemotingAppenderTests fail. Enabling internal logging gives the following error. log4net:ERROR [RemotingAppender] ErrorCode: GenericFailure. Failed in SendBufferCallback System.Runtime.Serialization.SerializationException: Because of security restrictions, the type System.Runtime.Remoting.ObjRef cannot be accessed. --- System.Security.SecurityException: Request failed. at System.Runtime.Serialization.FormatterServices.nativeGetSafeUninitializedObject(RuntimeType type) at System.Runtime.Serialization.FormatterServices.GetSafeUninitializedObject(Type type) The action that failed was: Demand The type of the first permission that failed was: System.Security.Permissions.SecurityPermission The first permission that failed was: IPermission class=System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 version=1 Flags=Infrastructure/ The demand was for: PermissionSet class=System.Security.PermissionSet version=1 IPermission class=System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 version=1 Flags=Infrastructure/ /PermissionSet The only permitted permissions were: PermissionSet class=System.Security.PermissionSet version=1 IPermission class=System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 version=1 Flags=SerializationFormatter/ /PermissionSet The method that caused the failure was: System.Runtime.Remoting.Channels.ServerProcessing ProcessMessage(System.Runtime.Remoting.Channels.IServerChannelSinkStack, System.Runtime.Remoting.Messaging.IMessage, System.Runtime.Remoting.Channels.ITransportHeaders, System.IO.Stream, System.Runtime.Remoting.Messaging.IMessage ByRef, System.Runtime.Remoting.Channels.ITransportHeaders ByRef, System.IO.Stream ByRef) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-269) custom log level
[ https://issues.apache.org/jira/browse/LOG4NET-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-269: --- Fix Version/s: 1.2 Maintenance Release custom log level Key: LOG4NET-269 URL: https://issues.apache.org/jira/browse/LOG4NET-269 Project: Log4net Issue Type: Task Components: Examples Affects Versions: 1.2.10 Environment: C# Reporter: Abhinay Priority: Critical Fix For: 1.2 Maintenance Release Original Estimate: 2h Remaining Estimate: 2h Can anyone know how to create custom log level and give priority to those custom levels ? Please help me with sample code. Thanks in advance Regards, Abhinay -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-268) Multiple messages logging
[ https://issues.apache.org/jira/browse/LOG4NET-268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-268. Resolution: Invalid This is a user-list question and not an issue tracker ticket. Maybe you want to use multiple calls to the logging methods to write multiple messages? If not then I'm afraid I don't understand the questions. Multiple messages logging - Key: LOG4NET-268 URL: https://issues.apache.org/jira/browse/LOG4NET-268 Project: Log4net Issue Type: New Feature Components: Other Affects Versions: 1.2.10 Environment: windows server 2008/ XP, C#.Net Reporter: Abhinay Priority: Critical Original Estimate: 24h Remaining Estimate: 24h Dear Team, I want to know is there anyway to log multiple messages for level information ? as of now log4net accepts only one message and other details like date time, thread details are saved. But I want more than one message to be saved(logged) to database/file . How can I do this. Please assist me in doing this. Thanks in advance. Regards, Abhinay -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-275) Update site content for Apache Project Branding Requirements
[ https://issues.apache.org/jira/browse/LOG4NET-275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-275: --- Fix Version/s: 1.2.11 Update site content for Apache Project Branding Requirements Key: LOG4NET-275 URL: https://issues.apache.org/jira/browse/LOG4NET-275 Project: Log4net Issue Type: Task Components: Documentation Reporter: Curt Arnold Fix For: 1.2.11 All Apache projects are to bring their sites into conformance with the Apache Project Branding requirements (http://www.apache.org/foundation/marks/pmcs) by Q1 2011. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-272) Problems in dynamic file naming with multiple appenders
[
https://issues.apache.org/jira/browse/LOG4NET-272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-272:
---
Fix Version/s: 1.2 Maintenance Release
Problems in dynamic file naming with multiple appenders
---
Key: LOG4NET-272
URL: https://issues.apache.org/jira/browse/LOG4NET-272
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: OS: Windows XP
Programming Environment: VB.NET
.NET Framework 3.5
Appender Type: RollingFileAppender
Reporter: Ranjith Nair
Priority: Critical
Fix For: 1.2 Maintenance Release
Original Estimate: 48h
Remaining Estimate: 48h
I have 3 appenders in my config file for creating 3 different types of logs.
I am using dynamic naming of file in each of the 3 appenders by setting the
global context properties. In some cases, i need to set the log file name
dynamically for just 1 appender. When i set the file name for just 1
appender, it creates another file named null with no data in addition to
the actual logfile whose name has been set dynamically.
appender name=RollingFileAppenderV1
type=log4net.Appender.RollingFileAppender
file type=log4net.Util.PatternString value=Logs\%property{applog} /
.
.
.
appender name=RollingFileAppenderV2
type=log4net.Appender.RollingFileAppender
file type=log4net.Util.PatternString value=Logs\%property{dblog} /
.
.
logger name=Logger1
level value=DEBUG /
appender-ref ref=RollingFileAppenderV1 /
/logger
logger name=Logger2
level value=DEBUG /
appender-ref ref=RollingFileAppenderV2 /
/logger
In the VB.NET code i set the filename as :
log4net.GlobalContext.Properties(applog) = file1.log
Dim logobj as log4net.Ilog = LogManager.GetLogger(Logger1)
logobj.debug(test)
In this case it creates file1.log and also another empty file with name as
null. This happens only when i am setting either of the appenders filename
at runtime.
Could you please check and let me know the issue behind this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-276) RollingFileAppender - File Location
[ https://issues.apache.org/jira/browse/LOG4NET-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-276: --- Fix Version/s: 1.2 Maintenance Release RollingFileAppender - File Location --- Key: LOG4NET-276 URL: https://issues.apache.org/jira/browse/LOG4NET-276 Project: Log4net Issue Type: Improvement Components: Appenders Environment: Windows Reporter: jrichview Fix For: 1.2 Maintenance Release Original Estimate: 4h Remaining Estimate: 4h I specified only the file name with no path so it, naturally, wrote the file to the current directory which turned out to be an unexpected folder. Googled, but didn't see an easy way to configure a RollingFileAppender (or FileAppender) to write the output file to the same folder as the log4net config file. It would also be nice to be able to specify that the file be written to whatever folder the log4net assembly is running from. I would've assumed this would be an easy/common config setting, but I couldn't find it anywhere. I'm still learning so if the feature already exists, please post. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-277) Registering a custom Object Renderer in configuration file
[ https://issues.apache.org/jira/browse/LOG4NET-277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-277: --- Fix Version/s: 1.2 Maintenance Release Does your appender live in RootNameSpace.dll? Registering a custom Object Renderer in configuration file -- Key: LOG4NET-277 URL: https://issues.apache.org/jira/browse/LOG4NET-277 Project: Log4net Issue Type: Bug Components: Other Affects Versions: 1.2.10 Environment: Windows .Net WebService Reporter: Daniel Shoubridge Fix For: 1.2 Maintenance Release When you include the line: renderer renderingClass=RootNameSpace.Namespace.RendererClass renderedClass=RootNameSpace.NameSpace.ClassToRender / in the configuration file and call: log4net.Config.XmlConfigurator.ConfigureAndWatch(New IO.FileInfo(logfile)) in global.asax, you get a TypeLoadException. Log4Net internal debugging outputs the following: log4net:ERROR OptionConverter: Could not instantiate class [LogLibrary.Log4NetObjRenderers.PdaLogObjRenderer]. System.TypeLoadException: Could not load type [LogLibrary.Log4NetObjRenderers.PdaLogObjRenderer]. Tried assembly [log4net, Version=1.2.10.0, Culture=neutral, PublicKeyToken=1b44e1d426115821] and all loaded assemblies at log4net.Util.SystemInfo.GetTypeFromString(Assembly relativeAssembly, String typeName, Boolean throwOnError, Boolean ignoreCase) in c:\work\svn_root\apache\log4net\tags\log4net-1.2.10-rc2\build\package\log4net-1.2.10\src\Util\SystemInfo.cs:line 671 at log4net.Util.SystemInfo.GetTypeFromString(String typeName, Boolean throwOnError, Boolean ignoreCase) in c:\work\svn_root\apache\log4net\tags\log4net-1.2.10-rc2\build\package\log4net-1.2.10\src\Util\SystemInfo.cs:line 602 at log4net.Util.OptionConverter.InstantiateByClassName(String className, Type superClass, Object defaultValue) in c:\work\svn_root\apache\log4net\tags\log4net-1.2.10-rc2\build\package\log4net-1.2.10\src\Util\OptionConverter.cs:line 477 log4net:ERROR XmlHierarchyConfigurator: Could not instantiate renderer [LogLibrary.Log4NetObjRenderers.PdaLogObjRenderer]. Work Around: 1, If you then stop the web server 2, and comment out the renderer line in the configuration file, 3, start the web service again, 4, then after it has started (global.asax has been processed) 5, uncomment the renderer line 6, the renderer will now work -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-280) Rolling appender doesnt roll 0kb file, configured to roll on date.
[ https://issues.apache.org/jira/browse/LOG4NET-280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-280: --- Fix Version/s: 1.2 Maintenance Release Rolling appender doesnt roll 0kb file, configured to roll on date. -- Key: LOG4NET-280 URL: https://issues.apache.org/jira/browse/LOG4NET-280 Project: Log4net Issue Type: Bug Components: Appenders Environment: asp.net 2.0 Reporter: Naveen Jakkur Muniraju Priority: Blocker Fix For: 1.2 Maintenance Release Original Estimate: 672h Remaining Estimate: 672h We are using a log4net version 1.2.10.1. We have a web application in which we are using log4net rolling appender for application logging. However the files which are 0Kb is not rolling on a daily basis. Below is the configuration we are using. It's configured to roll on a date basis. The logs which are 0kb are rolling fine. appender name=FileAppender type=log4net.Appender.RollingFileAppender param name=File value=D:\LogFiles\abc\abc_/ param name=AppendToFile value=true/ param name=RollingStyle value=Date/ param name=DatePattern value=MMdd.LOG/ param name=staticLogFileName value=false/ param name=ImmediateFlush value=true/ layout type=log4net.Layout.PatternLayout param name=ConversionPattern value=%d [%t] %-5p %c - %m%n/ /layout filter type=log4net.Filter.LevelRangeFilter param name=LevelMin value=DEBUG/ param name=LevelMax value=FATAL/ /filter /appender logger name=FileLogger level value=INFO/ appender-ref ref=FileAppender/ /logger Any help ASAP will be appreciated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-278) Type 'Common.Logging.Log4Net.Log4NetLogger' in Assembly 'Common.Logging.Log4Net, Version=1.2.0.2, Culture=neutral, PublicKeyToken=af08829b84f0328e' is not marked as ser
[ https://issues.apache.org/jira/browse/LOG4NET-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-278. Resolution: Invalid Whatever Common.Logging.* may be, it is not part of log4net Type 'Common.Logging.Log4Net.Log4NetLogger' in Assembly 'Common.Logging.Log4Net, Version=1.2.0.2, Culture=neutral, PublicKeyToken=af08829b84f0328e' is not marked as serializable. --- Key: LOG4NET-278 URL: https://issues.apache.org/jira/browse/LOG4NET-278 Project: Log4net Issue Type: Bug Environment: C#.Net 2008, Windows XP Reporter: Jothi Rmasamy Original Estimate: 24h Remaining Estimate: 24h Type 'Common.Logging.Log4Net.Log4NetLogger' in Assembly 'Common.Logging.Log4Net, Version=1.2.0.2, Culture=neutral, PublicKeyToken=af08829b84f0328e' is not marked as serializable. Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. Exception Details: System.Runtime.Serialization.SerializationException: Type 'Common.Logging.Log4Net.Log4NetLogger' in Assembly 'Common.Logging.Log4Net, Version=1.2.0.2, Culture=neutral, PublicKeyToken=af08829b84f0328e' is not marked as serializable. Source Error: An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-291) RollingFileAppender not working correctly when using DatePattern containing = 1 uppercase character in date format string literal
[ https://issues.apache.org/jira/browse/LOG4NET-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-291: --- Fix Version/s: 1.2 Maintenance Release RollingFileAppender not working correctly when using DatePattern containing = 1 uppercase character in date format string literal -- Key: LOG4NET-291 URL: https://issues.apache.org/jira/browse/LOG4NET-291 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.9, 1.2.10, 1.2.11 Environment: N.A. Reporter: Lee Chun Kit Priority: Minor Labels: bug Fix For: 1.2 Maintenance Release Original Estimate: 3h Remaining Estimate: 3h When using RollingFileAppender with a DatePattern containing at least 1 uppercase character in the form of a string literal, rolling of log files does not take place correctly. This is as curFileName is a lowercase string. To reproduce, see: http://mail-archives.apache.org/mod_mbox/logging-log4net-user/201104.mbox/%3CBANLkTi=lrapg7wijkb583gf7l5ystfe...@mail.gmail.com%3E Suggest change/fix to RollingFileAppender.cs: 1.2.9: 793c793 if (! curFileName.StartsWith(baseFile + m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo))) --- if (! curFileName.StartsWith(baseFile + m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture))) 1.2.10 816c816 if (! curFileName.StartsWith(baseFile + m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo))) --- if (! curFileName.StartsWith(baseFile + m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture))) Trunk: 885c885 if (! curFileName.StartsWith(CombinePath(baseFile, m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo --- if (! curFileName.StartsWith(CombinePath(baseFile, m_dateTime.Now.ToString(m_datePattern, System.Globalization.DateTimeFormatInfo.InvariantInfo).ToLower(System.Globalization.CultureInfo.InvariantCulture Work-about: Don't use uppercase characters in the form of a string literal for RollingFileAppender.DatePattern. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-307) New pattern AssemblyLocationPatternConverter
[
https://issues.apache.org/jira/browse/LOG4NET-307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-307:
---
Fix Version/s: 1.2 Maintenance Release
New pattern AssemblyLocationPatternConverter
Key: LOG4NET-307
URL: https://issues.apache.org/jira/browse/LOG4NET-307
Project: Log4net
Issue Type: New Feature
Components: Other
Affects Versions: 1.2.9, 1.2.10
Reporter: Jon Abaunza
Fix For: 1.2 Maintenance Release
It would be really easy and nice, to hace the
AssemblyLocationPatternConverter that would allow to retrieve the assembly of
the Caller.
using System;
using System.Text;
using System.IO;
using log4net.Core;
namespace log4net.Layout.Pattern
{ internal sealed class AssemblyLocationPatternConverter :
PatternLayoutConverter
{ override protected void Convert(TextWriter writer,
LoggingEvent loggingEvent)
{
writer.Write(loggingEvent.LocationInformation.AssemblyName);
}
}
}
It just would need the retrieval of the Assembly Name in the LocationInfo
(new property AssemblyName and the retrieval in the constructor)
...Retrieval
m_assembly = method.Module.Assembly.FullName;
...
After this... it just would be needed to register the new pattern so that it
would be recognized. (Added in the static constructor of PatternLayout)
s_globalRulesRegistry.Add(assembly,
typeof(AssemblyLocationPatternConverter));
With a conversion pattern like the following
conversionPattern value=%assembly/
We could get the following log:
WindowsFormsApplication3, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=null
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-298) Loggers are not fully re-entrant and can deadlock
[
https://issues.apache.org/jira/browse/LOG4NET-298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-298:
---
Fix Version/s: 1.2 Maintenance Release
Loggers are not fully re-entrant and can deadlock
-
Key: LOG4NET-298
URL: https://issues.apache.org/jira/browse/LOG4NET-298
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Reporter: Tanguy Fautre
Fix For: 1.2 Maintenance Release
Log4net internal locking seems to be too aggressive and coarse. It can
deadlock in cases where a logging thread waits on another thread that also
logs. While this is a similar issue to LOG4NET-225, there is no custom
appender needed to reproduce it.
For example, the following program will deadlock in
.\log4net-1.2.10\src\Appender\AppenderSkeleton.cs
(AppenderSkeleton.DoAppend(), line 296)
using System.Threading.Tasks;
using log4net;
using log4net.Appender;
using log4net.Core;
using log4net.Layout;
using log4net.Repository.Hierarchy;
namespace HelloWorldCSharp
{
public class Program
{
private static readonly ILog Log = LogManager.GetLogger(My.Logger);
private static void InitLogger()
{
var appender = new ConsoleAppender { Name = Unit Testing Console
Appender, Layout = new PatternLayout(%message%n), Threshold = Level.All };
appender.ActivateOptions();
var root = ((Hierarchy)LogManager.GetRepository()).Root;
root.Level = Level.Debug;
root.AddAppender(appender);
root.Repository.Configured = true;
}
public static void Main()
{
InitLogger();
Log.WarnFormat(Nasty thing {0}, new NastyThing());
}
private class NastyThing
{
public override string ToString()
{
Log.Warn(This message goes missing);
var t = Task.Factory.StartNew(DoLoggingInOtherThread);
t.Wait(); // this deadlock deep in log4net
return NastyThing.ToString();
}
}
public static void DoLoggingInOtherThread()
{
Log.Warn(This message deadlocks);
}
}
}
Current behaviour:
- prints nothing
- deadlocks
Expected behaviour:
- prints This message goes missing
- prints This message deadlocks
- prints Nasty thing NastyThing.ToString()
- exits cleanly
Having looked at the code from SkeletonAppender, I understand this may not be
a trivial issue to fix. I feel however that this is a reasonable user
expectation (especially given the fact that the use case above is read-only
and makes no attempt to modify the log tree).
Cheers,
Tanguy
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-308) Incorporate a compatibility checker to the build
[ https://issues.apache.org/jira/browse/LOG4NET-308?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-308: --- Fix Version/s: 1.2 Maintenance Release I agree this would be a good idea but don't know of anything similar to clirr for .NET assemblies. Incorporate a compatibility checker to the build Key: LOG4NET-308 URL: https://issues.apache.org/jira/browse/LOG4NET-308 Project: Log4net Issue Type: Task Reporter: Curt Arnold Fix For: 1.2 Maintenance Release The log4j build uses CLIRR to check that there have been no changes that break compatibility with previous releases. I would assume that there would have to be a similar tool in the .NET space and it would be beneficial to have any automated check instead of trying to find any changes via code review. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
First JIRA triage run complete
Hi all, as you have seen in the storm of JIRA emails I went through all JIRA issues and assigned them to some fix version. Some of them looked invalid but I only closed the most obvious ones. After I now have read all of them, on piece of code is sticking out as a major pain point: RollingFileAppender. A double digit number of issues are raised against it. I have assigned two or three of them to 1.2.11 but we can also push the whole thing back if it seems as if the code needs some re-thought to get it right. If anybody is looking for an isolated piece of code that needs to be fixed without any need to understand the whole code base, RollingFileAppender it is. If anybody wants to play with it, please raise your hand so we don't duplicate effort. The next things I intend to focus on is fixing the currently failing unit tests on Windows 7, generating the site (and fixing some related doc issues while I'm at it) and the whole build system so we can actually create a distribution. Stefan
[jira] [Created] (LOG4NET-310) EventLogAppender's ActivateOptions throws SecurityException on Vista/Win2k3 and later when not run as administrator
EventLogAppender's ActivateOptions throws SecurityException on Vista/Win2k3 and later when not run as administrator --- Key: LOG4NET-310 URL: https://issues.apache.org/jira/browse/LOG4NET-310 Project: Log4net Issue Type: Bug Affects Versions: 1.2.10 Reporter: Stefan Bodewig Fix For: 1.2.11 ActivateOptions uses EventLog.SourceExists which throws an exception of the source hasn't been found in any of the logs the user was allowed to read and there are others (in particular Security) that the user is not allowed to access. This is the reason of one of the unit test errors I reported in LOG4NET-301 Even if the code catches the exception and assumes the source doesn't exist this won't help as EventLog.CreateEventSource must not be called without administrator privileges either. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-254) [PATCH] Added Snmp V1 Trap Appender
[ https://issues.apache.org/jira/browse/LOG4NET-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098063#comment-13098063 ] Thomas Johnson commented on LOG4NET-254: Thanks, how do I do that? P.S. I've got a ipv6 patch for this should I recreate this patch ? [PATCH] Added Snmp V1 Trap Appender --- Key: LOG4NET-254 URL: https://issues.apache.org/jira/browse/LOG4NET-254 Project: Log4net Issue Type: New Feature Components: Appenders Environment: independent Reporter: Thomas Johnson Fix For: 1.2 Maintenance Release Attachments: SnmpTrapAppender.cs, SnmpTrapAppender.patch Original Estimate: 0h Remaining Estimate: 0h Added simple Snmp V1 Trap appender. Properties are based on configuration XML for log4j. I interpreted ApplicationTrapOID from the log4j appender to mean the ObjectOID for the message variable added to the TrapPDU. Uptime ticks PDU element based on time appender class is instantiated. Could be extended to include options for app pool uptime or time since last boot, etc. 4K character limit imposed on message length, extra cares will be truncated. Baseline revision: 881070 New File: apache-log4net\src\Appender\SnmpTrapAppender.cs Example Config: appender name=SnmpTrapAppender type=log4net.Appender.SnmpTrapAppender RemoteAddress value=127.0.0.1 / RemotePort value=162 / EnterpriseOID value=1.3.6.1.X.X.XXX.X.X / ApplicationTrapOID value=1.3.6.1.X.X.XXX.X.X.X.14 / CommunityString value=public / GenericTrapType value=EnterpriseSpecific / SpecificTrapType value=16 / layout type=log4net.Layout.PatternLayout conversionPattern value=%message / /layout /appender -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LOG4NET-311) MinimalLock and AppendToFile=false don#t work together in trunk's FileAppender
MinimalLock and AppendToFile=false don#t work together in trunk's FileAppender -- Key: LOG4NET-311 URL: https://issues.apache.org/jira/browse/LOG4NET-311 Project: Log4net Issue Type: Bug Components: Appenders Reporter: Stefan Bodewig Fix For: 1.2.11 As part of adding the MutextLock with LOG4NET-164 the logic that open the file has been factored out into a method of the base class of all locking models. The line that sets MinimalLock's m_append to true after opening the file has been lost on the way. This is responsible for two of the unit tests errors reported in LOG4NET-301. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-311) MinimalLock and AppendToFile=false don't work together in trunk's FileAppender
[ https://issues.apache.org/jira/browse/LOG4NET-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-311: --- Summary: MinimalLock and AppendToFile=false don't work together in trunk's FileAppender (was: MinimalLock and AppendToFile=false don#t work together in trunk's FileAppender) MinimalLock and AppendToFile=false don't work together in trunk's FileAppender -- Key: LOG4NET-311 URL: https://issues.apache.org/jira/browse/LOG4NET-311 Project: Log4net Issue Type: Bug Components: Appenders Reporter: Stefan Bodewig Fix For: 1.2.11 As part of adding the MutextLock with LOG4NET-164 the logic that open the file has been factored out into a method of the base class of all locking models. The line that sets MinimalLock's m_append to true after opening the file has been lost on the way. This is responsible for two of the unit tests errors reported in LOG4NET-301. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-164) using a named mutex for file appenders
[ https://issues.apache.org/jira/browse/LOG4NET-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098081#comment-13098081 ] Stefan Bodewig commented on LOG4NET-164: Note the patch has introduced an issue with MinimalLock that I've now resolved (LOG4NET-311). The third parameter of the create stream method that the patch adds is never used by anything - has this been intended to be used as forth paramter to the FileStream constructor? using a named mutex for file appenders -- Key: LOG4NET-164 URL: https://issues.apache.org/jira/browse/LOG4NET-164 Project: Log4net Issue Type: Improvement Components: Appenders Reporter: Frank Assignee: Ron Grabowski Fix For: 1.2.11 Attachments: MutexProcessLock.patch Original Estimate: 24h Remaining Estimate: 24h About logging to the same file from 2 or more instances of an application. As opposed to a minimallock which makes it still possible for 2 application instances to interfere. Why not use a named mutex so that the logging will wait for the lock to be released from another instance. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Does MinimalLock actually work with AppendToFile = false?
On 2011-09-06, Stefan Bodewig wrote: while looking into the failing unit tests I started to wonder whether TestMinimalLockUnlocks in RollingFileAppenderTest has ever passed - and if it actually can. I should have looked through svn history first. svn revision 607475 which adds the new (undocumented AFAICS) MutextLock LockingModel has broken the test by removing a tiny little line (resetting m_append to true after opening the file for the first time). Should be fixed in a second. Stefan
[jira] [Commented] (LOG4NET-254) [PATCH] Added Snmp V1 Trap Appender
[ https://issues.apache.org/jira/browse/LOG4NET-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13098091#comment-13098091 ] Stefan Bodewig commented on LOG4NET-254: Yes, I think you should re-create them. When you upload the patch(es), there is a checkbox you need to check in order to grant a license to the ASF. [PATCH] Added Snmp V1 Trap Appender --- Key: LOG4NET-254 URL: https://issues.apache.org/jira/browse/LOG4NET-254 Project: Log4net Issue Type: New Feature Components: Appenders Environment: independent Reporter: Thomas Johnson Fix For: 1.2 Maintenance Release Attachments: SnmpTrapAppender.cs, SnmpTrapAppender.patch Original Estimate: 0h Remaining Estimate: 0h Added simple Snmp V1 Trap appender. Properties are based on configuration XML for log4j. I interpreted ApplicationTrapOID from the log4j appender to mean the ObjectOID for the message variable added to the TrapPDU. Uptime ticks PDU element based on time appender class is instantiated. Could be extended to include options for app pool uptime or time since last boot, etc. 4K character limit imposed on message length, extra cares will be truncated. Baseline revision: 881070 New File: apache-log4net\src\Appender\SnmpTrapAppender.cs Example Config: appender name=SnmpTrapAppender type=log4net.Appender.SnmpTrapAppender RemoteAddress value=127.0.0.1 / RemotePort value=162 / EnterpriseOID value=1.3.6.1.X.X.XXX.X.X / ApplicationTrapOID value=1.3.6.1.X.X.XXX.X.X.X.14 / CommunityString value=public / GenericTrapType value=EnterpriseSpecific / SpecificTrapType value=16 / layout type=log4net.Layout.PatternLayout conversionPattern value=%message / /layout /appender -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-311) MinimalLock and AppendToFile=false don't work together in trunk's FileAppender
[ https://issues.apache.org/jira/browse/LOG4NET-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-311. Resolution: Fixed fixed with svn revision 1165715 MinimalLock and AppendToFile=false don't work together in trunk's FileAppender -- Key: LOG4NET-311 URL: https://issues.apache.org/jira/browse/LOG4NET-311 Project: Log4net Issue Type: Bug Components: Appenders Reporter: Stefan Bodewig Fix For: 1.2.11 As part of adding the MutextLock with LOG4NET-164 the logic that open the file has been factored out into a method of the base class of all locking models. The line that sets MinimalLock's m_append to true after opening the file has been lost on the way. This is responsible for two of the unit tests errors reported in LOG4NET-301. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-7) Detecting NoAppenderWarning
[ https://issues.apache.org/jira/browse/LOG4NET-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-7: - Fix Version/s: (was: 1.2.11) 1.2 Maintenance Release Detecting NoAppenderWarning --- Key: LOG4NET-7 URL: https://issues.apache.org/jira/browse/LOG4NET-7 Project: Log4net Issue Type: Improvement Components: Core Environment: From sourceforge - 785036 Reporter: Nicko Cadell Assignee: Ron Grabowski Fix For: 1.2 Maintenance Release It would be nice to be able to detect an event related to NoAppenderWarning. That is, one might want to take arbitrary actions when a logger category has no appenders attached to it, which is often caused by some kind of problem, usually related to configuration. Thanks for considering this suggestion. Anonymous -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-136) logger conversionPattern restriction doesn't work correctly for Generic classes
[
https://issues.apache.org/jira/browse/LOG4NET-136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-136:
---
Fix Version/s: (was: 1.2.11)
1.2 Maintenance Release
logger conversionPattern restriction doesn't work correctly for Generic
classes
---
Key: LOG4NET-136
URL: https://issues.apache.org/jira/browse/LOG4NET-136
Project: Log4net
Issue Type: Bug
Affects Versions: 1.2.10
Environment: Windows 2000 Professional, .NET Framework 2.0
Reporter: Tom Crossland
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2 Maintenance Release
Attachments: ConsoleApplication3-GenericPrettyPrinter.zip
conversionPattern value=%date %-5level %logger{1} - %message%newline/
Using the above conversion pattern for a logger of a Generic class (i.e.
My.System.MyClassMy.System.MyObject) will result in the following log
output:
2008-01-17 21:54:48,968 INFO 0, Culture=neutral, PublicKeyToken=null]] - My
error message
Obviously, in this case it's not appropriate to just take the portion of the
class name after the last '.' character.
Thanks
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-211) Log4net with MS Access 2007 for asp.net 3.5 website
[ https://issues.apache.org/jira/browse/LOG4NET-211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-211: --- Fix Version/s: (was: 1.2.11) 1.2 Maintenance Release Log4net with MS Access 2007 for asp.net 3.5 website --- Key: LOG4NET-211 URL: https://issues.apache.org/jira/browse/LOG4NET-211 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows XP, VS 2008, MS Access 2007 Reporter: sundeep Fix For: 1.2 Maintenance Release Original Estimate: 840h Remaining Estimate: 840h Hello, I am using log4net for asp.net 3.5 website for logging exceptions into the MS Access 2007 (*accdb ). I had done following settings: 1. Created log4net config file ?xml version=1.0 encoding=utf-8 ? log4net debug=false appender name=AdoNetAppender_Access type=log4net.Appender.AdoNetAppender connectionString value=Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|EAlog.accdb;Persist Security Info=False; / commandText value=INSERT INTO Logs ([LogDate],[Thread],[Level],[Logger],[Message]) VALUES (@LogDate, @Thread, @Level, @Logger, @Message) / parameter parameterName value=@LogDate / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%date / /layout /parameter parameter parameterName value=@Thread / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%thread / /layout /parameter parameter parameterName value=@Level / dbType value=String / size value=50 / layout type=log4net.Layout.PatternLayout conversionPattern value=%level / /layout /parameter parameter parameterName value=@Logger / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%logger / /layout /parameter parameter parameterName value=@Message / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%message / /layout /parameter /appender !--root level value=DEBUG / appender-ref ref=AdoNetAppender_Access/ /root-- logger name=File level value=All / appender-ref ref=AdoNetAppender_Access / /logger /log4net !--log4net root level value=DEBUG / appender-ref ref=RollingLogFileAppender/ /root appender name=RollingFileAppender type=log4net.Appender.RollingFileAppender file value=logsapp.log / appendToFile value=true / rollingStyle value=Size / maxSizeRollBackups value=10 / maximumFileSize value=100KB / staticLogFileName value=true / layout type=log4net.Layout.PatternLayout conversionPattern value=%d [%t]%-5p %c [%x] - %m%n / /layout /appender appender name=RollingLogFileAppender type=log4net.Appender.RollingFileAppender file value=logsapp.log / appendToFile value=false / datePattern value=- / rollingStyle value=Date / layout type=log4net.Layout.PatternLayout conversionPattern value=%d [%t]%-5p %c [%x] - %m%n / /layout /appender /log4net-- !--Log4net-- !--log4net appender name=AdoNetAppender_Access type=log4net.Appender.AdoNetAppender connectionString value=Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|Logs.accdb;Persist Security Info=False; / commandText value=INSERT INTO Logs ([LogDate],[Thread],[Level],[Logger],[Message]) VALUES (?, ?, ?, ?, ?) / parameter parameterName value=LogDate / dbType value=DateTime / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%LogDate / /layout /parameter parameter parameterName value=Thread / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%Thread / /layout /parameter parameter parameterName value=Level / dbType value=String / size value=50 / layout type=log4net.Layout.PatternLayout conversionPattern value=%Level / /layout /parameter parameter parameterName value=Logger / dbType value=String / size value=255 / layout type=log4net.Layout.PatternLayout conversionPattern value=%Logger / /layout /parameter parameter parameterName value=Message / dbType value=String / size value=1024 / layout
[jira] [Updated] (LOG4NET-221) Store log in database using log4net
[ https://issues.apache.org/jira/browse/LOG4NET-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig updated LOG4NET-221: --- Fix Version/s: (was: 1.2.11) 1.2 Maintenance Release this really is a user-list question and not an issue tracker-ticket so I'm leaning towards INVALD myself. Store log in database using log4net --- Key: LOG4NET-221 URL: https://issues.apache.org/jira/browse/LOG4NET-221 Project: Log4net Issue Type: Wish Affects Versions: 1.2.10 Environment: Win XP, Visual studio 2005 (framework 2.0) Reporter: Mai Lam Fix For: 1.2 Maintenance Release Hi master, Please help me: how to store log in database (MS SQL) using log4net. I want to store log in a table with structure as following: Table: Order Columns: + OrderID (int) + Volume (int) + Price (Decimal) + Side (Char) I found the configuration file that declare connection string, command text, parameters. But i don't know to implement. Is there the way to pass parameters into Info method? ex: Log.Info(OrderID, Volume, Price, Side). I've already review source code of log4net, but i don't know how to override Info method with multiple parameters Please help me. Thank a lot -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (LOG4NET-231) App hangs on log attempt when non-contiguous rolling log files exist
[ https://issues.apache.org/jira/browse/LOG4NET-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Bodewig resolved LOG4NET-231. Resolution: Not A Problem Fix Version/s: (was: 1.2.11) App hangs on log attempt when non-contiguous rolling log files exist Key: LOG4NET-231 URL: https://issues.apache.org/jira/browse/LOG4NET-231 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Win32, Win Server 2003, C# app Reporter: John Fairhall Application has this log4net config: log4net appender name=RollingFile type=log4net.Appender.RollingFileAppender file value=..\log\OOPCollector.log / appendToFile value=false / maximumFileSize value=5MB / maxSizeRollBackups value=5 / lockingModel type=log4net.Appender.FileAppender+MinimalLock / layout type=log4net.Layout.PatternLayout conversionPattern value=%date %5level [%thread] %logger - %message%newline / /layout /appender root level value=INFO / appender-ref ref=RollingFile / /root /log4net We are attemping to keep current + 5 backup logs. Somehow, the resulting logs for the OOPCollector app became; OOPCollector.log OOPCollector.log.5 Starting the app with only those logs already existing causes the app to stop on a log attempt permanently. The OOPCollector.log.5 log dissappears but the OOPCollector.log does not get renamed to OOPCollector.log.1, and no new OOPCollector.log is created. The issue also occurs if the directory contains OOPCollector.log OOPCollector.log.4 except that .4 does get renamed to .5, but otherwise same problem. Directory containining OOPCollector.log OOPCollector.log.3 works as expected. Have set config to store 10 backups, and have same issue with OOPCollector.log and OOPCollector.log.10, and OOPCollector.log and OOPCollector.log.9. So looks like a fencepost error with rollover. We are also getting OOPCollector.timestamp.1, .2, .3 files in the directory occaisionally for no apparent reason. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (LOG4NET-281) Insufficient Granularity on Log methods in ILog
[
https://issues.apache.org/jira/browse/LOG4NET-281?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-281:
---
Fix Version/s: (was: 1.2.11)
2.0
Putting it back to a release where we are willing to break backwards
compatibility.
You could always bypass ILog's convenience layer and use the ILogger instance
avaliable via the Logger property directly.
Insufficient Granularity on Log methods in ILog
---
Key: LOG4NET-281
URL: https://issues.apache.org/jira/browse/LOG4NET-281
Project: Log4net
Issue Type: New Feature
Components: Core
Affects Versions: 1.2.10
Environment: All Environments
Reporter: Zev
Fix For: 2.0
Original Estimate: 2h
Remaining Estimate: 2h
The driver for this change is that we are unable to log certain event types
from the ILog object. While we can use the Logger object, it is easier to
have them here.
updated code:
ILog.cs
//start new
void Emergency(object message);
void Emergency(object message, Exception e);
void Alert(object message);
void Alert(object message, Exception e);
void Critical(object message);
void Critical(object message, Exception e);
void Notice(object message);
void Notice(object message, Exception e);
//end new
LogImpl.cs (in ReloadLevels)
//start new
m_levelEmergency = levelMap.LookupWithDefault(Level.Emergency);
m_levelAlert = levelMap.LookupWithDefault(Level.Alert);
m_levelCritical = levelMap.LookupWithDefault(Level.Critical);
m_levelNotice = levelMap.LookupWithDefault(Level.Notice);
//end new
methods:
//start new
virtual public void Emergency(object message)
{
Logger.Log(ThisDeclaringType, m_levelEmergency, message, null);
}
virtual public void Emergency(object message, Exception exception)
{
Logger.Log(ThisDeclaringType, m_levelEmergency, message,
exception);
}
virtual public void Alert(object message)
{
Logger.Log(ThisDeclaringType, m_levelAlert, message, null);
}
virtual public void Alert(object message, Exception exception)
{
Logger.Log(ThisDeclaringType, m_levelAlert, message, exception);
}
virtual public void Critical(object message)
{
Logger.Log(ThisDeclaringType, m_levelCritical, message, null);
}
virtual public void Critical(object message, Exception exception)
{
Logger.Log(ThisDeclaringType, m_levelCritical, message,
exception);
}
virtual public void Notice(object message)
{
Logger.Log(ThisDeclaringType, m_levelNotice, message, null);
}
virtual public void Notice(object message, Exception exception)
{
Logger.Log(ThisDeclaringType, m_levelNotice, message, exception);
}
//end new
private fields:
//start new
private Level m_levelEmergency;
private Level m_levelAlert;
private Level m_levelCritical;
private Level m_levelNotice;
//end new
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: First JIRA triage run complete
I will take on RFA. I have had my issues with it and even added a different rolling method for my local use. This brings us back to how do I get the current code with any additions to start working from. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Tuesday, September 06, 2011 08:28 To: log4net-dev@logging.apache.org Subject: First JIRA triage run complete Hi all, as you have seen in the storm of JIRA emails I went through all JIRA issues and assigned them to some fix version. Some of them looked invalid but I only closed the most obvious ones. After I now have read all of them, on piece of code is sticking out as a major pain point: RollingFileAppender. A double digit number of issues are raised against it. I have assigned two or three of them to 1.2.11 but we can also push the whole thing back if it seems as if the code needs some re-thought to get it right. If anybody is looking for an isolated piece of code that needs to be fixed without any need to understand the whole code base, RollingFileAppender it is. If anybody wants to play with it, please raise your hand so we don't duplicate effort. The next things I intend to focus on is fixing the currently failing unit tests on Windows 7, generating the site (and fixing some related doc issues while I'm at it) and the whole build system so we can actually create a distribution. Stefan
