[jira] [Commented] (LOG4NET-342) Add a way to prevent silent failure
[ https://issues.apache.org/jira/browse/LOG4NET-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13679984#comment-13679984 ] Ron Grabowski commented on LOG4NET-342: --- The IsEnabled's come in handy when you want check at a higher level if particular logger/level pair is enabled. Sometimes code takes a very different logic path when trace is enabled. That determination is made separately from the actual tracing. Do you expect log.IsConfigured to be called a lot outside of an application's startup code? I have a feeling most applications will call it just once. I'd hate to clutter up the main interface with a member that gets called infrequently and will always have the same value across all ILogs. LogManager.GetRepository().Configured still seems good enough. As far as discoverability goes, I fired up VS and found the property by navigating through a few small intellisense lists: log.Logger.Repository.Configured Let's assume log.IsConfigured==false, now where do I go? At some point they're going to have to deal with the repository to figure out what the problem is. I say we keep them close to the repository since that's what they're ultimately configuring and that's what they'll need to inspect before using ILog instances. Add a way to prevent silent failure --- Key: LOG4NET-342 URL: https://issues.apache.org/jira/browse/LOG4NET-342 Project: Log4net Issue Type: New Feature Reporter: Joachim Zobel Assignee: Dominik Psenner Priority: Minor Fix For: 1.2.12 I spent most of the day trying to find out why logging is not working on my dev system but not on test. There should be a way to force error reporting by throwing (possibly unhandled) exceptions. This could be done by adding a required flag to the appenders and another flag that requires a least one working appender. I am not sure about a good way to implement this, I would just love it if my favourite tool to end silent failure could stop failing silently. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-373) AdoNetAppender truncates the data while inserting into DB
[ https://issues.apache.org/jira/browse/LOG4NET-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13621533#comment-13621533 ] Ron Grabowski commented on LOG4NET-373: --- That sounds odd. How many characters are being saved to your tables? AdoNetAppender truncates the data while inserting into DB - Key: LOG4NET-373 URL: https://issues.apache.org/jira/browse/LOG4NET-373 Project: Log4net Issue Type: Bug Environment: SQL Server 2008 R2, VS 2010 Reporter: Vijay Gandhi Bolla Priority: Critical I am using Log4net to log request and response of my services into SQL server DB. I am serializing the request and response objects and saving them into DB. I have seen that log4net is truncating the xml text and saving it into DB. I am using string type in the table and also in the appender i have given String as Dbtype and given the Size value as '2147483647'. But still the text is getting trimmed. Please, let me know if this is an issue or am i missing something here. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-345) log file naming issue
[
https://issues.apache.org/jira/browse/LOG4NET-345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13397229#comment-13397229
]
Ron Grabowski commented on LOG4NET-345:
---
Did you try Google or stackoverflow.com?
http://stackoverflow.com/questions/1165084/log4net-rolling-daily-filename-with-date-in-the-file-name
param name=DatePattern value=dd.MM.'.log' /
log file naming issue
-
Key: LOG4NET-345
URL: https://issues.apache.org/jira/browse/LOG4NET-345
Project: Log4net
Issue Type: Bug
Components: Appenders
Environment: Asp.net application
Reporter: akanksha gupta
Priority: Critical
hi,
i am using log4net in my asp.net application,
How can I change the configuration so files are rolled to
[FileName][Date].[ext] rather than [FileName].[ext][Date]
my web.config file is as follows:-
log4net
logger name=WebTFEUI
level value=ALL/
appender-ref ref=RollingFile/
/
logger
appender name=RollingFile type=log4net.Appender.RollingFileAppender
!--
rollingStyle value=Composite /
datePattern value=MMdd /
preserveLogFileNameExtension value=true/
--
!--
file
Sets the file where the log output will go.
--
file value=Log/SantorinEditor.log/
!--
appendToFile
Gets or sets a flag that indicates weather the file should be
appended to or overwritten.
If the value is set to false then the file will be overwritten, if
it is set to true then the file will be appended to.
--
appendToFile value=true/
!--
rollingMode
Style of rolling to use
1. Roll files based only on the size of the file Size.
2. Roll files based only on the date Date.
--
rollingMode value=Size/
!--
maxSizeRollBackups
Gets or sets the maximum number of backup files that are kept before
the oldest is erased.
If set to zero, then there will be no backup files and the log file
will be truncated when it reaches MaxFileSize.
--
maxSizeRollBackups value=10/
!--
maximumFileSize
Gets or sets the maximum size that the output file is allowed to reach
before being rolled over to backup files.
--
maximumFileSize value=1024/
!--
staticLogFileName
Gets or sets a value indicting whether to always log to the same file.
true if always should be logged to the same file, otherwise false.
By default(true) file.log is always the current file. Optionally(false)
file.log.-mm-dd for current formatted datePattern can be the currently
logging file.
--
staticLogFileName value=true/
layout type=log4net.Layout.PatternLayout
conversionPattern value=%d{-MM-dd HH:mm:ss} %p : %m%n/
/
layout
!--
filter
This is a simple filter based on Level matching.
The filter admits below options
1. LevelMin
2. LevelMax
that determine the range of priorities that are matched.
Priorities of levels.
ERRORWARNINFO1INFO2INFO3INFO4
--
filter type=log4net.Filter.LevelRangeFilter
param name=LevelMin value=ERROR/
param name=LevelMax value=INFO3/
/
filter
/
appender
/
log4net
currently i am using 1.2.0 version of log4net and i found 1.2.11 version has
fix this issue so by just changing rollingFileappender.cs can solve my
problem or not??
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck application process
[
https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13288947#comment-13288947
]
Ron Grabowski commented on LOG4NET-344:
---
When I posted a link to AsyncBulkInsertAppender.cs I wanted the focus to be
more on the threading code rather than limiting it to just BulkInsert
operations.
Taking the interesting parts AsyncBulkInsertAppender.cs and extending
BufferingForwardingAppender gives us async support in about 30 lines of code:
//
https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs
protected override void SendBuffer(LoggingEvent[] events)
{
ThreadPool.QueueUserWorkItem(delegate
{
lock (syncLock)
{
eventsList.AddLast(events);
if (anotherThreadAlreadyHandlesLogging)
return;
anotherThreadAlreadyHandlesLogging = true;
}
while (true)
{
LoggingEvent[] current;
lock (syncLock)
{
if (eventsList.Count == 0)
{
anotherThreadAlreadyHandlesLogging = false;
return;
}
current = eventsList.First.Value;
eventsList.RemoveFirst();
}
base.SendBuffer(current);
}
});
}
Some suggestions for improving your AsyncForwardingAppender...change the
variable names that reference File and make the buffer size settable. I don't
see the benefit of using dedicated thread in this case because you aren't
giving the thread a chance to shutdown and process its messages when the
repository shutsdown. Modern CLRs have lots of threads available in the pool,
just use one of those.
Make AdoNetAppender not to stuck application process
Key: LOG4NET-344
URL: https://issues.apache.org/jira/browse/LOG4NET-344
Project: Log4net
Issue Type: Improvement
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows series
Reporter: Tom Tang
Labels: patch
Fix For: 3.5
Attachments: AdoNetAppender.cs, AsyncForwardingAppender.cs
Original Estimate: 24h
Remaining Estimate: 24h
The original AdoNetAppender could stuck application during log insertion.
Because it use the sync method call to do database insert, once the DB is
unavailable or table was locked.
I change the implementation that has an inner queue inside to store the
messages, and the other independent thread will be going to cunsuming the
queue messages and do DB insertion.
This implementation will not have any impact on application performance and
much stable.
Trade off: Once the queue max buffer was full, the later coming log message
would be ignored and gone forever. But log4net is not designed for guarantee
delivery in purpose, right? So it's not big deal at all. :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-344) Make AdoNetAppender not to stuck application process
[ https://issues.apache.org/jira/browse/LOG4NET-344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13287014#comment-13287014 ] Ron Grabowski commented on LOG4NET-344: --- I recommend using this: https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs Make AdoNetAppender not to stuck application process Key: LOG4NET-344 URL: https://issues.apache.org/jira/browse/LOG4NET-344 Project: Log4net Issue Type: Improvement Components: Appenders Affects Versions: 1.2.10 Environment: Windows series Reporter: Tom Tang Labels: patch Fix For: 3.5 Attachments: AdoNetAppender.cs Original Estimate: 24h Remaining Estimate: 24h The original AdoNetAppender could stuck application during log insertion. Because it use the sync method call to do database insert, once the DB is unavailable or table was locked. I change the implementation that has an inner queue inside to store the messages, and the other independent thread will be going to cunsuming the queue messages and do DB insertion. This implementation will not have any impact on application performance and much stable. Trade off: Once the queue max buffer was full, the later coming log message would be ignored and gone forever. But log4net is not designed for guarantee delivery in purpose, right? So it's not big deal at all. :) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-342) Add a way to prevent silent failure
[
https://issues.apache.org/jira/browse/LOG4NET-342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13285164#comment-13285164
]
Ron Grabowski commented on LOG4NET-342:
---
Not too difficult to stop your app from starting up if logging isn't configured:
if (log.IsErrorEnabled == false)
{
throw new ConfigurationErrorsException(Log4net failed to initialize
properly.);
}
Add a way to prevent silent failure
---
Key: LOG4NET-342
URL: https://issues.apache.org/jira/browse/LOG4NET-342
Project: Log4net
Issue Type: New Feature
Reporter: Joachim Zobel
Priority: Minor
Fix For: 1.2.12
I spent most of the day trying to find out why logging is not working on my
dev system but not on test. There should be a way to force error reporting by
throwing (possibly unhandled) exceptions. This could be done by adding a
required flag to the appenders and another flag that requires a least one
working appender.
I am not sure about a good way to implement this, I would just love it if my
favourite tool to end silent failure could stop failing silently.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (LOG4NET-332) I'm looking for the ability to set up a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders
Maybe OpenFile isn't the best place to look for error. If you want access to a
logging event so you can send it somewhere else if writing to the appender
fails you'll probably need to check that the previous write was successful
higher up in the chain in one of the DoAppend methods. I'll keep thinking about
this and try to write some code.
From: stalinsubash (Commented) (JIRA) j...@apache.org
To: log4net-dev@logging.apache.org
Sent: Wednesday, April 18, 2012 6:59 AM
Subject: [jira] [Commented] (LOG4NET-332) I'm looking for the ability to set up
a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could
then log to one of more back-up appenders
[
https://issues.apache.org/jira/browse/LOG4NET-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256436#comment-13256436
]
stalinsubash commented on LOG4NET-332:
--
Thanks Ron.
I successfully implemented Failover in ADONetAppender. If ADONet fails then it
will rollover to FileAppender \ EventViewerAppender. Here I attached the
ADONetAppender class file as well.
But I FileAppender I’ll fail, I can’t able to get Logging Event in FileAppender
class. Here I’ll explain what scenario I tried. I tried to write a log in a
text file but the path I mentioned in the configuration file was wrong, so
while writing the log it will search the path to open the file in the method
(OpenFile) in FileAppender class file, so in the try catch block I implemented
below codes as well,
public override void OpenFile(string filename, bool append,Encoding encoding)
{
try
{
m_stream = CreateStream(filename, append, FileShare.Read);
}
catch (Exception ex)
{
LoggingEvent[] events = new LoggingEvent[0];
//events = (LoggingEvent[]);
string message = FileAppender failed to find the path;
// Pass the logging event on to the attached appenders if
there are any
if (iAppenderAttachedImpl != null)
{
iAppenderAttachedImpl.AppendLoopOnAppenders(events);
}
else
{
message += and there is no appender-ref specified
in the configuration for fail-over!;
}
ErrorHandler.Error(message, ex);
}
}
Could you please advise me on this ASAP?
Thanks
Stalin.M
I'm looking for the ability to set up a hierarchy of appenders, if a log to
an ADONETAppender fails, log4net could then log to one of more back-up
appenders
--
Key: LOG4NET-332
URL: https://issues.apache.org/jira/browse/LOG4NET-332
Project: Log4net
Issue Type: New Feature
Components: Appenders
Affects Versions: 1.2.9
Environment: windows 7 , VS2010
Reporter: stalinsubash
Priority: Blocker
Labels: patch
Original Estimate: 24h
Remaining Estimate: 24h
Basically, I'm looking for the ability to set up a hierarchy of appenders so
that if a log to an ADONETAppender fails, log4net could then log to one of
more back-up appenders, for example, a RollingLogFile or SMTP
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (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 ] Ron Grabowski reassigned LOG4NET-148: - Assignee: Ron Grabowski 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 Assignee: Ron Grabowski 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. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LOG4NET-332) I'm looking for the ability to set up a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders
[ https://issues.apache.org/jira/browse/LOG4NET-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski closed LOG4NET-332. - Resolution: Won't Fix This isn't a bug in log4net. You need to write your own appender by extending a class like ForwardingAppender: appender name=SimpleRolloverForwardingAppender type=MyCompany.SimpleRolloverForwardingAppender, MyCompany appender-ref ref=AdoNetAppender / appender-ref ref=SmtpAppender / /appender You don't need to make any changes to log4net.dll to accomplish what you want. I'm looking for the ability to set up a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders -- Key: LOG4NET-332 URL: https://issues.apache.org/jira/browse/LOG4NET-332 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.9 Environment: windows 7 , VS2010 Reporter: stalinsubash Priority: Blocker Labels: patch Original Estimate: 24h Remaining Estimate: 24h Basically, I'm looking for the ability to set up a hierarchy of appenders so that if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders, for example, a RollingLogFile or SMTP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (LOG4NET-332) I'm looking for the ability to set up a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders
[ https://issues.apache.org/jira/browse/LOG4NET-332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski closed LOG4NET-332. - Resolution: Duplicate See LOG4NET-1 I'm looking for the ability to set up a hierarchy of appenders, if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders -- Key: LOG4NET-332 URL: https://issues.apache.org/jira/browse/LOG4NET-332 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.9 Environment: windows 7 , VS2010 Reporter: stalinsubash Priority: Blocker Labels: patch Original Estimate: 24h Remaining Estimate: 24h Basically, I'm looking for the ability to set up a hierarchy of appenders so that if a log to an ADONETAppender fails, log4net could then log to one of more back-up appenders, for example, a RollingLogFile or SMTP -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-331) AdoNetAppender errors when writing Asp.net item when Request object is null
[
https://issues.apache.org/jira/browse/LOG4NET-331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251223#comment-13251223
]
Ron Grabowski commented on LOG4NET-331:
---
At first glance it looks like it pattern does account for Request being null:
// AspNetRequestPatternConverter
protected override void Convert(TextWriter writer, LoggingEvent loggingEvent,
HttpContext httpContext)
{
if (httpContext.Request != null)
{
if (Option != null)
{
WriteObject(writer, loggingEvent.Repository,
httpContext.Request.Params[Option]);
}
else
{
WriteObject(writer, loggingEvent.Repository,
httpContext.Request.Params);
}
}
else
{
writer.Write(SystemInfo.NotAvailableText);
}
}
AdoNetAppender errors when writing Asp.net item when Request object is null
---
Key: LOG4NET-331
URL: https://issues.apache.org/jira/browse/LOG4NET-331
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.11
Environment: Windows Server 2008 R2
Reporter: Andy Smith
Priority: Minor
When using AdoNetAppender, with a conversion pattern of
'%aspnet-request{REMOTE_ADDR}', and I attempt to write a log entry during the
Application_Start event, it throws an error (internally) and stops working.
The error refers to ...Request is not available in this context.. which
makes sense because its only in the Application_Start event. However the
appender should accommodate this situation and log null, not throw an error.
The RollingFileAppender, for instance, handles this gracefully.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-266) AdoNetAppender does not work on a IIS 7 website using Windows authentication
[
https://issues.apache.org/jira/browse/LOG4NET-266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251229#comment-13251229
]
Ron Grabowski commented on LOG4NET-266:
---
Catching ObjectDisposedException in this case seems ok with me.
AdoNetAppender does not work on a IIS 7 website using Windows authentication
-
Key: LOG4NET-266
URL: https://issues.apache.org/jira/browse/LOG4NET-266
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.10
Environment: Windows Server 2008, IIS 7, ASP.Net Framework v4.0, Sql
Server 2008, Windows Authentication Activated
Reporter: Kaider
Priority: Critical
Fix For: 1.2 Maintenance Release
Original Estimate: 4h
Remaining Estimate: 4h
When the Windows Authentication is deactivated, the AdoNetAppender works
properly.
Howerver, once the Windows authentication is activated, the AdoNetAppender
start working properly and then, after a few seconds, it is aborted and the
following error message is retrieved:
log4net:ERROR [AdoNetAppender] Failed in DoAppend
System.ObjectDisposedException: Safe handle has been closed
at System.Runtime.InteropServices.SafeHandle.DangerousAddRef(Boolean
success)
at System.StubHelpers.StubHelpers.SafeHandleAddRef(SafeHandle pHandle,
Boolean success)
at Microsoft.Win32.Win32Native.GetTokenInformation(SafeTokenHandle
TokenHandle, UInt32 TokenInformationClass, SafeLocalAllocHandle
TokenInformation, UInt32 TokenInformationLength, UInt32 ReturnLength)
at
System.Security.Principal.WindowsIdentity.GetTokenInformation(SafeTokenHandle
tokenHandle, TokenInformationClass tokenInformationClass)
at System.Security.Principal.WindowsIdentity.get_User()
at System.Security.Principal.WindowsIdentity.GetName()
at System.Security.Principal.WindowsIdentity.get_Name()
at log4net.Core.LoggingEvent.get_Identity()
at log4net.Core.LoggingEvent.FixVolatileData(FixFlags flags)
at log4net.Appender.BufferingAppenderSkeleton.Append(LoggingEvent
loggingEvent)
at log4net.Appender.AppenderSkeleton.DoAppend(LoggingEvent loggingEvent)
See below the settings of the appender. Various options (i.e. Securitycontext
) have also been tested in vain.
appender name=AdoNetAppender_SqlServer
type=log4net.Appender.AdoNetAppender
bufferSize value=1 /
connectionType value=System.Data.SqlClient.SqlConnection,
System.Data, Version=1.0.3300.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089 /
connectionString value=data source=WW;initial
catalog=X;integrated security=false;persist security info=True;User
ID=sa;Password= /
commandText value=sp_LOG_Insert/
commandType value=StoredProcedure /
parameter
parameterName value=@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=@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=8000 /
layout type=log4net.Layout.PatternLayout
value=%message /
/parameter
/appender
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Proposed bug fix for AspNetRequestPatternConverter.Convert()
The converter is trying to protect itself...the base class checks to make sure
HttpContext.Current is not null then a check against Request is made:
// AspNetRequestPatternConverter
protected override void Convert(TextWriter writer, LoggingEvent loggingEvent,
HttpContext httpContext)
{
if (httpContext.Request != null)
{
if (Option != null)
{
WriteObject(writer, loggingEvent.Repository,
httpContext.Request.Params[Option]);
}
else
{
WriteObject(writer, loggingEvent.Repository,
httpContext.Request.Params);
}
}
else
{
writer.Write(SystemInfo.NotAvailableText);
}
}
Sounds like checking the property throws an exception. Its probably ok to just
add in a try/catch and document that the problems with trying to check Request.
From: George Chung geo...@glympse.com
To: Log4NET Dev log4net-dev@logging.apache.org
Sent: Friday, March 30, 2012 7:53 PM
Subject: Re: Proposed bug fix for AspNetRequestPatternConverter.Convert()
Hi Alessandro,But you are already checking for a null HttpContext and
outputting NOTAVAILABLE in that case, which means that the code was intended
to deal with format layouts of %aspnet{xxx} and HttpContext's that were null.
I'm simply suggesting that the code should ALSO deal with HttpContext's that
have a bad Request property.
As motivation for this change, you have people who are using log4net in
Application_Start in Classic Mode and it works fine. The behavior that they'll
see as they upgrade to the recommended Integrated Pipeline mode is that this
logging will disappear mysteriously.
Finally, there is no other place to initialize the ASP.NET application. The
only place to do it is in the Application_Start(). So if they are using the
%aspnet layout format in their logging, then they'll basically see no logging
in this code path.
It's not a huge issue, and I can live without it (or I can modify the code as I
have), and I can see why you don't like the suggested fix, but again, I think
the catch block will only fire very rarely in an application's lifetime and it
will allow ASP.NET users who are currently using log4net from being confused as
they upgrade to the Integrated Pipeline mode.
Thanks for listening, and it has been very nice to see such prompt and
thoughtful response from the log4net dev team. The product is great.
Cheers,
George
On Fri, Mar 30, 2012 at 3:35 PM, Alessandro Ghizzardi box.ml...@phaseit.com
wrote:
Yes that's exactly the point. If log4net need the request and you're calling it
in a scope that doesn't have it, catching the error in log4net doesn't seem a
viable solution for my point of view because it'll not work as expected without
request.
Probably it's better to move the app initializiation code in a scope that
actually have the request available as you can read in the article.
Best
Alessandro Ghizzardi
Moving...
Il giorno 30/mar/2012, alle ore 23:54, Johnson, Thomas
thomas.john...@lpsvcs.com ha scritto:
It sounds like he’s suggesting you fix your site instead of the codebase? If
there’s definitely a fix that needs to be in place, I would explore the
httpContext to see if you can infer whether get_Request would throw an NRE and
check that instead of try/catch – it’s just a code smell everyone should try
to avoid in general
From:George Chung [mailto:geo...@glympse.com]
Sent: Friday, March 30, 2012 3:50 PM
To: Log4NET Dev
Subject: Re: Proposed bug fix for AspNetRequestPatternConverter.Convert()
Yes, that is exactly the issue. Just my humble opinion, but Log4Net would
only incur the try/catch perf penalty during user logging inside
Application_Start, which is a very tiny percentage of the lifetime of an
ASP.Net application.
The issue for log4net is that people staticly define their layout patterns
that they want in the web.config. It's not obvious to me how they could
instruct log4net to ignore the aspnet layout patterns while inside
Application_Start.
I don't know any other way to test the viability of calling through
get_Request() before the fact.
Cheers,
George
On Fri, Mar 30, 2012 at 2:30 PM, Alessandro Ghizzardi box.ml...@phaseit.com
wrote:
Hi George,
It seems more like an architecture problem in logging that point, instead of
a bug. It used to work in older version, but probably you're using IIS7 in
integrated mode and request is not available anymore.
If you really need to log in application start probably this workaround can
help you
http://mvolo.com/blogs/serverside/archive/2007/11/10/Integrated-mode-Request-is-not-available-in-this-context-in-Application_5F00_Start.aspx
Best
Alessandro Ghizzardi
Moving...
Il giorno 30/mar/2012, alle ore 22:59, George Chung geo...@glympse.com ha
scritto:
The subtlety is that in Application_Startup(), httpContext is indeed not null
and httpContext.Request is really httpContext.get_Request().
And it is the act of
[jira] [Commented] (LOG4NET-327) in AppenderSkeleton.Append should check next Filter while got a FilterDecision.Neutral
[
https://issues.apache.org/jira/browse/LOG4NET-327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13238068#comment-13238068
]
Ron Grabowski commented on LOG4NET-327:
---
Why do you think that? The break means the switch statement will exit and
return control to the while loop.
in AppenderSkeleton.Append should check next Filter while got a
FilterDecision.Neutral
--
Key: LOG4NET-327
URL: https://issues.apache.org/jira/browse/LOG4NET-327
Project: Log4net
Issue Type: Bug
Components: Appenders
Affects Versions: 1.2.9
Reporter: LoyeMei
Labels: AppenderSkeleton.Append
public void DoAppend(LoggingEvent loggingEvent)
{
while(f != null)
{
switch(f.Decide(loggingEvent))
{
case FilterDecision.Deny:
return; // Return without appending
case FilterDecision.Accept:
f = null; // Break out of the loop
break;
case FilterDecision.Neutral:
f = f.Next; // Move to next filter
break;//Error here ,It
should be continue here
}
}
...
}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Who owns the log4net nuget package?
Does anyone know who owns the log4net nuget package? http://nuget.org/packages/log4net http://blog.cincura.net/232619-log4net-back-alive-on-nuget/ We're the 6th most populate package on nuget! Can someone explain what it would take to get the nuget package files into our svn repository?
SDK docs on apache.org don't display properly
Anyone know why there are extended chars in most of the log4net ndoc files? For example this page has empty-blocks in IE9 and triangle-question-marks in Firefox: http://logging.apache.org/log4net/release/sdk/log4net.Appender.BufferingAppenderSkeleton.Evaluator.html
[jira] [Commented] (LOG4NET-87) Support ASP.Net related PatternConverters to allow items from the HttpContext.Current.Session, Cache, Request, etc. to be captured.
[
https://issues.apache.org/jira/browse/LOG4NET-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177748#comment-13177748
]
Ron Grabowski commented on LOG4NET-87:
--
Have you tried fixing the fields before sending data to another thread?
http://logging.apache.org/log4net/release/sdk/log4net.Core.FixFlags.html
You'll probably need to tweak your appender to evaluate the values before
sending to another thread. Take a look at BufferingAppenderSkeleton's Fix
property:
http://logging.apache.org/log4net/release/sdk/log4net.Appender.BufferingAppenderSkeleton.Fix.html
Hopefully its degrading gracefully.
Support ASP.Net related PatternConverters to allow items from the
HttpContext.Current.Session, Cache, Request, etc. to be captured.
---
Key: LOG4NET-87
URL: https://issues.apache.org/jira/browse/LOG4NET-87
Project: Log4net
Issue Type: Wish
Components: Core
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2.11
It would be nice if there were built-in Pattern Converters to support core
ASP.Net objects:
%aspnet-session{UserId}
%aspnet-session
%aspnet-request{ProductId}
This issue may be a good time to investigate supporting a more advanced
syntax for the Option parameter:
%aspnet-request{queryString:ProductId}
that could be shared across all Pattern Converters.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-320) Location Information
[ https://issues.apache.org/jira/browse/LOG4NET-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13177548#comment-13177548 ] Ron Grabowski commented on LOG4NET-320: --- It looks like your patch only works for layouts derived from XmlLayoutBase. Wouldn't it be more useful in LayoutSkeleton? Location Information Key: LOG4NET-320 URL: https://issues.apache.org/jira/browse/LOG4NET-320 Project: Log4net Issue Type: New Feature Components: Core Affects Versions: 1.2.11 Reporter: Adam Davies Priority: Minor Labels: location, locationoffset, patch, stacktrace Fix For: 1.2 Maintenance Release Attachments: LocationOffset.patch Add the ability to offset the stacktrace information. On occasion there is a need to skip the first n stack locations. For example, if using a generic method to log exceptions and then rethrow them; the generic method is irrelevant information in the stack. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Dropping Support for .NET CF 1.0 and SSCLI 1.0 in log4net 1.2.11
+1 From: Stefan Bodewig bode...@apache.org To: log4net-dev@logging.apache.org; log4net-u...@logging.apache.org Sent: Tuesday, September 20, 2011 12:41 PM Subject: Dropping Support for .NET CF 1.0 and SSCLI 1.0 in log4net 1.2.11 Hi all, sorry for the cross-post but I'd like to catch oh no, you can't do that! responses as soon as possible. Apart from a few documentation and packaging issues Apache log4net 1.2.11 seems to be pretty much ready for a release. One thing that is holding up the process is the - let's say dated - build environment required to build all target binaries. So far I've been able to set up a machine with all SDKs that are freely available - what I'm still missing are the .NET Compact Framework 1.0 and SSCLI 1.0. It seems as if CF 1.0 requires an installation of Visual Studio (2003, likely) while it was sufficient to install the .NET 2.0 SDK in order to build the CF 2.0 assemblies. For SSCLI I can find the sources but it requires Visual C++ to build. So before I try to find Visual Studio 2003 - and accept that you can't build a log4net release without an IDE you have to pay for - I thought I might simply ask if anybody was opposed to have log4net 1.2.11 simply strike the two platforms. We will poll users for future directions later, so please let us limit this thread to the two frameworks in question. Stefan
Re: [jira] [Resolved] (LOG4NET-87) Support ASP.Net related PatternConverters to allow items from the HttpContext.Current.Session, Cache, Request, etc. to be captured.
Oh those TODOs...I didn't see those when I looked at the code for the aspnet
patterns themselves. It didn't occur to me that the parent class that included
the patterns was missing documentation
From: Stefan Bodewig (JIRA) j...@apache.org
To: log4net-dev@logging.apache.org
Sent: Tuesday, September 20, 2011 11:22 AM
Subject: [jira] [Resolved] (LOG4NET-87) Support ASP.Net related
PatternConverters to allow items from the HttpContext.Current.Session, Cache,
Request, etc. to be captured.
[
https://issues.apache.org/jira/browse/LOG4NET-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig resolved LOG4NET-87.
---
Resolution: Fixed
Missing documentation added with svn revision 1173186
Support ASP.Net related PatternConverters to allow items from the
HttpContext.Current.Session, Cache, Request, etc. to be captured.
---
Key: LOG4NET-87
URL: https://issues.apache.org/jira/browse/LOG4NET-87
Project: Log4net
Issue Type: Wish
Components: Core
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2.11
It would be nice if there were built-in Pattern Converters to support core
ASP.Net objects:
%aspnet-session{UserId}
%aspnet-session
%aspnet-request{ProductId}
This issue may be a good time to investigate supporting a more advanced
syntax for the Option parameter:
%aspnet-request{queryString:ProductId}
that could be shared across all Pattern Converters.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-235) IP Address Pattern Converter
[ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104037#comment-13104037 ] Ron Grabowski commented on LOG4NET-235: --- I don't think having one aspnet pattern converter was the problem with those. It was more of a do we really want/need to expose _all_ the properties relating to HttpContext via pattern convertors? IP Address Pattern Converter Key: LOG4NET-235 URL: https://issues.apache.org/jira/browse/LOG4NET-235 Project: Log4net Issue Type: New Feature Components: Other Affects Versions: 1.2.10 Reporter: Adam Davies Priority: Trivial Fix For: 1.2 Maintenance Release Attachments: log4net - IP Address.zip Original Estimate: 0h Remaining Estimate: 0h Created AspNetIPAddressPatternConverter to provide the client IP Address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: diffs between 1.2.10 and current trunk
The signature changes from void to ICollection shouldn't break anything. Now the configurators return a list of configuration messages. I suppose it should return an array of a certain type instead of just ICollection. Maybe something like ConfigurationMessage[] or LogLog[]. I lean more towards ConfigurationMessage[]...LogLog sounds like it came from the Department of Redundancy Department. Calls to LogLog are now required to pass in the Type of the caller which replaced inconsistent string identifiers to identify the source of internal log messages. From: Stefan Bodewig bode...@apache.org To: log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 10:51 AM Subject: diffs between 1.2.10 and current trunk Hi all, in order to shape up for the release I diffed the 1.2.10 release ZIP source tree against current trunk's src and used BitDiffer from bitwidgets[1] to compare the DEBUG assemblies targeting 2.0 in binary. The results can be found in http://people.apache.org/~bodewig/log4net/diffs/ The source code diffs are mainly there so we can put together proper release notes and see whether there are changes not covered by resolved JIRA issues. They may also be useful to catch mistakes now, but that is going to require a long time and sharp eyes, I'm afraid. I've set up BitDiffer to not compare implementations but really only signatures. The breaking changes it flags right now: (1) the several variations of static Configure methods in configurators now return ICollection, they used to be void methods. (2) ConverterInfo used to be a nested class of PatternLayout and has been moved to the Util namespace. (3) The signature of the CreateLogger method in ILoggerFactory has changed. (4) Several LogLog method signatures have changed. Of this only (3) really concerns me as I consider ConverterInfo and LogLog internal to log4net and the change in return type shouldn't cause anything to break IMHO. The change in ILoggerFactory happend in svn revision 515275[2] for LOG4NET-97[3]. Back then Nicko was aware this was breaking BWC (the commit log says so) but accepted it as necessary. This likely means we should document the change and live with it. Stefan [1] http://bitwidgets.com/ [2] https://svn.apache.org/viewvc?view=revisionrevision=515275 [3] https://issues.apache.org/jira/browse/LOG4NET-97
Re: Name for MutexLock?
I don't have any hard numbers but the last time I played around with MinimalLock it was very very slow. I view InterProcessLock as an intermediary between exclusive and minimal locking. From: Dominik Psenner dpsen...@gmail.com To: 'Log4NET Dev' log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 8:37 AM Subject: RE: Name for MutexLock? LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Are we talking about the variable name? In that case I would prefer a name that makes it obvious what it is behind: MutexLock :-) Did you actually do performance tests too? A mutex is rather expensive and it should be avoided to acquire/release it multiple times unless really necessary. Greetings, D.
[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=13104050#comment-13104050 ] Ron Grabowski commented on LOG4NET-164: --- I like the name InterProcessLock 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: Name for MutexLock?
Can you share a config snippet showing how to use the RemotingAppender like you've described? What happens when one of the apps goes down? I envision the InterProcessLock as a locking model used between two low/medium chatty apps that want to write to the same file that may or may not be running at the same time. From: Roy Chastain r...@roychastain.org To: Log4NET Dev log4net-dev@logging.apache.org Sent: Tuesday, September 13, 2011 9:25 AM Subject: RE: Name for MutexLock? I like InterProcessLock and would like to propose MultiProcessLock as my favorite. I HOPE that the documentation will indicate what a bad plan this is and that a remoteing appender etc might be a better plan. -- Roy Chastain -Original Message- From: Stefan Bodewig [mailto:bode...@apache.org] Sent: Tuesday, September 13, 2011 06:47 To: log4net-dev@logging.apache.org Subject: Name for MutexLock? Hi, LOG4NET-164 introduced a new locking strategy for FileAppender which technically uses a System.Threading.Mutex with a name built from the log file's name. This should allow separate processes to share a log file without repeatedly opening and closing it. The main remaining issue is its name (apart from docs which will follow once the name is settled). Right now it is called MutexLock but that may not convey to users what this actually does - they'd need to know what a Mutex is in the first place. I'm notoriously bad at names so I'm asking here now. Names suggested in the JIRA ticket are InterProcessLock, SystemWideLock and GlobalLock. Stefan
[jira] [Commented] (LOG4NET-235) IP Address Pattern Converter
[ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103300#comment-13103300 ] Ron Grabowski commented on LOG4NET-235: --- I checked the 5 AspNet classes just now and they all have documentation IP Address Pattern Converter Key: LOG4NET-235 URL: https://issues.apache.org/jira/browse/LOG4NET-235 Project: Log4net Issue Type: New Feature Components: Other Affects Versions: 1.2.10 Reporter: Adam Davies Priority: Trivial Fix For: 1.2 Maintenance Release Attachments: log4net - IP Address.zip Original Estimate: 0h Remaining Estimate: 0h Created AspNetIPAddressPatternConverter to provide the client IP Address. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (LOG4NET-151) Cache DateTime.Now values when creating LoggingEvent when Environment.TickCount has not changed
[
https://issues.apache.org/jira/browse/LOG4NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13101362#comment-13101362
]
Ron Grabowski commented on LOG4NET-151:
---
A further optimization might be to allow the user to set the timestamp
granularity at the log event generation stage for the repository. Some apps
might only care about logging events down to the second level rather than at
the millisecond level...or some fraction in between. Think SMALLDATETIME vs
DATETIME2 in SQL Server.
log4net.DateFormatter.AbsoluteTimeDateFormatter does this already when it
recognizes that it doesn't need to update the string representation of the
timestamp if nothing has changed from when it last generated. It also has the
lock() statement you mentioned.
Some other implementations might be:
- DefaultDateTime
Today's functionality using standard DateTime.Now or DateTime.UtcNow
- CachedDateTime
Cache DateTime.Now similar to AbsoluteTimeDateFormatter down to some user
specific granularity
- TickCountOffset
Record DateTime.Now once on startup then use Environment.TickCount to calculate
current time based on offset from start time. Another call to DateTime.Now must
take place as the offset nears Int32.MaxValue to avoid overflow. Maybe ~25
days??? This might help boost the performance of chatty apps that are always
recycled each day.
- Win32GetSystemTime
Maybe in FullTrust environments there are faster ways to get the current
time...or at least some numeric representation of the time that can then be
quickly turned into a real DateTime object without calling DateTime.Now
Cache DateTime.Now values when creating LoggingEvent when
Environment.TickCount has not changed
---
Key: LOG4NET-151
URL: https://issues.apache.org/jira/browse/LOG4NET-151
Project: Log4net
Issue Type: Improvement
Affects Versions: 1.2.10
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Priority: Minor
Fix For: 1.2.11
When creating a lot of logging events in tight loop, DateTime.Now is called
for each new LoggingEvent even if several LoggingEvents are created within
the same millisecond. We can reuse the same DateTime object because DateTime
objects only track time down to the millisecond:
// inspired by nlog
int ticks = Environment.TickCount;
if (ticks != cachedTicks)
{
cachedTicks = ticks;
cachedDateTime = DateTime.Now;
}
return cachedDateTime;
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Distribution Formats
New key? I think I Nicko sent me the current assembly keya long time ago. People always complain when keys change From: Stefan Bodewig bode...@apache.org To: log4net-dev@logging.apache.org Sent: Thursday, September 8, 2011 12:26 AM Subject: Distribution Formats Hi all, 1.2.10 is distributed as a single ZIP with source and binaries for all supported platforms. Normal ASF procedure is to have separate downloads for source-only and binary-plus-doc releases and to provide ZIPs as well as tar.gz tarballs. How do we want to package 1.2.11? I personally would stick with ZIPs only but create three archives: source only, binaries signed with new key plus docs, binaries signed with old key plus docs. Any other preferences? Stefan
Re: State of Client Profile and .NET 4.0 Support
Is your .NET 4 support just in the NAnt scripts? It's probably safe to replace the VS2008 solution file with a VS2010 version. From: Stefan Bodewig bode...@apache.org To: log4net-dev@logging.apache.org Sent: Saturday, August 20, 2011 6:14 AM Subject: State of Client Profile and .NET 4.0 Support Hi all, I've hacked in client profile support - the NAnt build files are becoming a bigger mess of copy-paste with each change, but this is a different story. I've taken Tasos' approach and defined a CLIENT_PROFILE compilation symbol and conditionally excluded the ASP.NET stuff if it is present and in addition NAnt won't reference System.Web. I haven't performed any extensive testing but at least I was able to build a minimal client profile command line app and write a log message to a file using the 3.5 Client Profile assembly created (which in reality is a 2.0 Client Profile assembly). For 4.0 this doesn't work, but it is not due to Client Profile but to the security related exception I already raised in a different thread. As soon as I try to load any type from any of the two assemblies targeting 4.0 a TypeLoadException is raised because of Inheritance security rules violated while overriding member: 'log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)'. Security accessibility of the overriding method must match the security accessibility of the method being overriden. log4net.Util.ReadOnlyPropertiesDictionary.GetObjectData(System.Runtime.Serialization.SerializationInfo, System.Runtime.Serialization.StreamingContext)} So this isn't related to ADO.NET as I suspected in the other thread. Of the three patches attached to LOG4NET-233 two contain security related attributes in the 4.0 case - but they take different approaches. I'll have to read up on the differences of the security models and the ramifications of either approach before deciding what to do. I can't promise this will happen this weekend (rather unlikely). Any advice from people with more (should I say any?) knowledge is welcome 8-) Stefan
Re: Is log4net in a cul-de-sac ?
I still use log4net every day across several large projects and check the mailing lists several times a week. All my stuff is still on 3.5 still so I haven't been hit by any of the 4.0 issues. I don't know how much a new release targeting just 1.1, 2.0, and 3.5 would benefit people right considering 4.0 has been out for a while. What probably needs to happen is support for 1.0 and 1.1 needs dropped, support for 4.0 (including Client Profile) needs added, and we need to start to migrate things over to use generics. I'm not sure how to handle things like Compact Framework and Silverlight. I don't use those technologies and don't have a large interest in writing code for those frameworks. Would removing support for those two things, upgrading to VS2010 and .NET 4.0, then re-adding them later be a huge headache? From: Tasos Vogiatzoglou tvog...@gmail.com To: log4net-dev@logging.apache.org Sent: Wednesday, July 20, 2011 6:13 AM Subject: Is log4net in a cul-de-sac ? Hello all, It seems that there is very little activity on the log4net dev side. Bugs remain unfixed, no release schedules, sparse activity on the repository. E.g. the official release has a long standing bug with IPv6 and having an unofficial build (that is one that is not signed with apache key) is not working for lots of people that use other libraries that have dependencies on the strong named log4net assembly (.NET does not permit assembly redirection among different public tokens). If there is no plan, could we, somehow, help to make a release for log4net having these fixes so we can benefit from an official log4net release? Regards Tasos Vogiatzoglou
Re: System.FormatException: Index (zero based) must be greater than or equal to zero
Ummm, what does TabbedOutput look like? From: mc_line mc_line_...@yahoo.com.mx To: log4net-dev@logging.apache.org Sent: Monday, May 30, 2011 1:18 PM Subject: System.FormatException: Index (zero based) must be greater than or equal to zero Hi I keep getting the error bellow but only in a XP while I am not getting any error in my Win7 development PC. log4net:ERROR AppenderAttachedImpl: Failed to append to appender [] System.FormatException: Index (zero based) must be greater than or equal to zero and less than the size of the argument list. at System.Text.StringBuilder.AppendFormat(IFormatProvider provider, String fo rmat, Object[] args) at System.String.Format(IFormatProvider provider, String format, Object[] arg s) at LauncherGUI.TestOutputDisplay.TabbedOutput.DoAppend(LoggingEvent loggingEv ent) at log4net.Util.AppenderAttachedImpl.AppendLoopOnAppenders(LoggingEvent loggi ngEvent) Anyone has any idea. This is killing me This is my code to configure the appended _TabbedOutput = new TabbedOutput(); log4net.Config.BasicConfigurator.Configure(_TabbedOutput); ((log4net.Repository.Hierarchy.Hierarchy)log4net.LogManager.GetRepository()).Root.AddAppender(_TabbedOutput); Thanks -- View this message in context: http://old.nabble.com/System.FormatException%3A-Index-%28zero-based%29-must-be-greater-than-or-equal-to-zero-tp31734898p31734898.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
Re: Log4net Asynchronous Logging
https://github.com/lorenzomelato/rhino-commons/blob/master/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs - Original Message - From: anjansingh mailan...@hotmail.com To: log4net-dev@logging.apache.org Cc: Sent: Monday, April 11, 2011 5:09 AM Subject: RE: Log4net Asynchronous Logging Thanks for yoyr reply. Actually I am going to build and application in ASP.NET that requires logging of exceptions in SQL Server. For that purpose I need to log exception details in database asynchronously. Dominik Psenner wrote: Howdie, would you please be more specific? What should be asynchronous? Greetings, D. -Original Message- From: anjansingh [mailto:mailan...@hotmail.com] Sent: Monday, April 11, 2011 7:35 AM To: log4net-dev@logging.apache.org Subject: Log4net Asynchronous Logging Hi All, Can anybody plz give me code walkthru of how to do a Asynchronous logging using Log4net? I have been searching for sometime but cound not get any helpful link. Any useful help would do the needful. Urgent help needed. -- View this message in context: http://old.nabble.com/Log4net-Asynchronous- Logging-tp31367440p31367440.html Sent from the Log4net - Dev mailing list archive at Nabble.com. -- View this message in context: http://old.nabble.com/Log4net-Asynchronous-Logging-tp31367440p31368437.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
Re: [jira] Created: (LOG4NET-285) Issue with rolling based on a date
10 programs writing to the same file? That's a lot. RollingFileAppender isn't process-safe. From: kinnar (JIRA) j...@apache.org To: log4net-dev@logging.apache.org Sent: Friday, February 18, 2011 9:45 AM Subject: [jira] Created: (LOG4NET-285) Issue with rolling based on a date Issue with rolling based on a date -- Key: LOG4NET-285 URL: https://issues.apache.org/jira/browse/LOG4NET-285 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: windows server 2003,dotnet framework3.5, wcf services Reporter: kinnar Priority: Blocker Fix For: 1.2.10 Hi, We are having 10 programs which are rolling into same log file namlely logger.log. Below is configuration of RollingFileAppender which we are using : appender name=RollFile type=log4net.Appender.RollingFileAppender threshold value =ALL/ file value=C:\logger.log / param name=LockingModel type=log4net.Appender.FileAppender+MinimalLock / appendToFile value=true / maximumFileSize value=1GB / staticLogFileName value=true/ maxSizeRollBackups value=5 / datePattern value=.-MM-dd-ttquot;.logquot;/ rollingStyle value=Composite / layout type=log4net.Layout.PatternLayout /layout /appender Our rolling based on date is running at every 12 hour span means at 12 Noon and 12 Midnight. Now what is happening when multiple programs try to log into log file at the same time when rolling happens means at 12 noon/midnight, then size of file getting rolled is becoming very small compare to original file size(i.e Suppose logger.log is around 1 MB at 12 noon, when rolling happens the new rolled file which is get generated is around 3 KB or somewhat). So, almost data get lost due to this. This is basically happening when multiple programs try to log into log file at the same time of when rolling happens(means at 12 noon/midnight). Debugging Info: I have debug this issue by enabling debugging in log4net. What is happing when 2 or more programs try to log into log file at time of roll time means at 12 midnight/12 noon, then from first program call RollOverTime() function in log4net source code gets called. It will in turn call RollFile() , which in turn check whether rolled file with particular date and time exist, if yes then its deleting that file and creating new roll file with particular date and time and moving content of original log file into new roll log file. Till now its fine. But as second request for logging comes at same time means at 12 midnight/12 noon , it will also call RolloverTime(), then RollFile(), which in turn find rolled file with particular date and time. so, it will delete that rolled file with particular and date and create a new roll file and move content of original log file into it.At that time original log file contains very less data. So, thats why size of rolled log file is becoming very low. Very less size of rolled file is a major issue of it . All of you might get my whole debugging description described above. Please revert back to us on this ASAP as its very important us to go ahead. Regards, Kinnar -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (LOG4NET-279) Disabling Log4net
[ https://issues.apache.org/jira/browse/LOG4NET-279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12936004#action_12936004 ] Ron Grabowski commented on LOG4NET-279: --- log4net.LogManager.Shutdown() -or- log4net.LogManager.GetAllRepositories().ToList().ForEach(r = r.Threshold = Level.Off); 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12936005#action_12936005 ] Ron Grabowski commented on LOG4NET-278: --- The issue is with the Common.Logging.Log4Net assembly which isn't 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. - You can reply to this email to add a comment to the issue online.
Re: AW: [jira] Created: (LOG4NET-257) Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory
I just read that nant has a new release candidate out that supports .NET 4.0. Someone may want to try running that against the code base as that's how the final releases are built. - Original Message From: Dominik Psenner dpsen...@gmail.com To: Log4NET Dev log4net-dev@logging.apache.org Sent: Fri, April 30, 2010 2:41:39 AM Subject: AW: [jira] Created: (LOG4NET-257) Visual Studio 2010 .NET 4.0 Application does not copy log4net lib to bin directory There are more compatibility problems with log4net and .NET 4.0 and actually nobody knows what will be.
Re: abandoned?
I agree with getting out a small point release before a large refactor. - Original Message From: steven higgan steven.hig...@gmail.com To: Log4NET Dev log4net-dev@logging.apache.org Sent: Sun, May 2, 2010 10:03:47 PM Subject: Re: abandoned? yes please, drop 1.1 - its so 7 or so years ago... before any major refactor is done to require .net 2.0 can a new release be made, there is a lot of stuff in trunk that would heal some pain. cheers. On Mon, May 3, 2010 at 1:57 PM, Ron Grabowski rongrabow...@yahoo.com wrote: Its not dead. I read the mailing list every day and the mailing list does a decent job of answering questions. I think the current code base is stable and extensible. I had intended to get another release out to support 1.1 but I think that opportunity has passed now that 4.0 has been released. If we don't want to support 1.1 anymore we can start to migrate the code to generics and target .NET 2.0 as the base. From: Kirill Temnenkov kirill.temnen...@gmail.com To: log4net-dev@logging.apache.org Sent: Thu, April 29, 2010 6:45:48 AM Subject: abandoned? Hi! I think that the project be abandoned. Am I right? Can I participate in the development as a developer? WBR, Kirill Temnenkov
[jira] Resolved: (LOG4NET-248) Log4Net won't log in production environment while it works in development environment
[ https://issues.apache.org/jira/browse/LOG4NET-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-248. --- Resolution: Invalid Doesn't sound like the problem is with log4net if it works correctly in your dev environment. Try posting your question on one of the mailing lists or enable log4net's internal debugging to trace what's going wrong. Log4Net won't log in production environment while it works in development environment - Key: LOG4NET-248 URL: https://issues.apache.org/jira/browse/LOG4NET-248 Project: Log4net Issue Type: Bug Affects Versions: 1.2.10 Environment: Windows Server 2003 R2, SharePoint, MOSS 2007, Web farm environment. Reporter: Amit Gupta Priority: Critical Fix For: 1.2.10 We have several SharePoint web apps on the production server with similar setup on test, int and dev environments. But the issue is that log4net logs in all environments for all SharePoint web apps EXCEPT ONE web app. Couldn't figure out what could be the possible reason. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Getting a signed version of the latest build of log4net
You should be able to build both from their respective trunks then reference your build where appropriate? From: Preet Sangha preet.san...@aderant.com To: log4net-dev@logging.apache.org log4net-dev@logging.apache.org Sent: Sun, December 13, 2009 5:28:09 PM Subject: Getting a signed version of the latest build of log4net Can anyone please tell me how I can get a signed version of log4net without signing it myself? We use N-Hibernate and would like to use the current version or log4net please. Many thanks preet Attention: Any e-mail sent from ADERANT may contain information which is CONFIDENTIAL and/or privileged. Unless you are the intended recipient, you may not disclose, copy or use it. Please notify the sender immediately and delete it and any copies from your systems. You should protect your system from viruses etc.; we accept no responsibility for damage that may be caused by them.
Re: how to contribute?
Hi Eike, I received your email. The best thing to do is comment, vote, or write patches for these items for the 1.2.11 release: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truemode=hidesorter/order=DESCsorter/field=priorityresolution=-1pid=10690fixfor=12310980 If you think any of the other open items should be included post a comment on those tickets as well. This ticket implements a FileAppender locking model using a Mutex: https://issues.apache.org/jira/browse/LOG4NET-164 I'd like someone to review my code before I close the ticket. Do you think MutexLock is a good name for the class? http://svn.apache.org/viewvc/logging/log4net/trunk/src/Appender/FileAppender.cs?view=markup Is there a better name such that the implementation isn't the same name as the class or is it ok in this situation? - Original Message From: Eike Falk eikef...@web.de To: log4net-dev@logging.apache.org Sent: Mon, December 7, 2009 4:36:44 AM Subject: how to contribute? Hello Ron, I have written you an email last week to your configured email address rongrabow...@yahoo.com regarding how I might contribute to the log4net project. Maybe this address is not the right one? Could you pl. let me know if and how I could contribute to the project? Thx, Eike Falk __ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de
[jira] Assigned: (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message
[
https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Grabowski reassigned LOG4NET-154:
-
Assignee: Ron Grabowski
Add a StackTracePatternConverter to display method calls leading up to log
message
--
Key: LOG4NET-154
URL: https://issues.apache.org/jira/browse/LOG4NET-154
Project: Log4net
Issue Type: New Feature
Reporter: Ron Grabowski
Assignee: Ron Grabowski
Fix For: 1.2.11
Attachments: log4net - StackTrace and StackTraceDetail.zip,
StackTracePatternConverter.zip
Modify LocationInfo to save StackTrace information and make it available as
StackTracePatternConverter to display call stack leading up to the log
message:
log.Debug(Item Saved);
[%stackTrace{3}] %message%newline
[default_aspx.btnSubmit_Click productController.Save
productService.Save] Item Saved
This will probably be a slow pattern converter on par with other LocationInfo
derived pattern converters.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-225) Multithreading and Deadlocks
[ https://issues.apache.org/jira/browse/LOG4NET-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-225. --- Resolution: Invalid Don't log while logging within the same LoggerRepository. Multithreading and Deadlocks Key: LOG4NET-225 URL: https://issues.apache.org/jira/browse/LOG4NET-225 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Reporter: Thomas Haller Priority: Blocker Attachments: Log4NetDeadlock.zip If an Appender has to execute some logic on another thread, witch uses also log4net, this leads to a deadlock. The sample project i created demonstrates that problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-235) IP Address Pattern Converter
[ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12778669#action_12778669 ] Ron Grabowski commented on LOG4NET-235: --- Can you think of a better way to expose properties of HttpContext? Request, Session, Cache, etc. all have a lot of useful properties. Should we code up patterns for each and every possibility or just add them on an added needed basis as the community needs them? IP Address Pattern Converter Key: LOG4NET-235 URL: https://issues.apache.org/jira/browse/LOG4NET-235 Project: Log4net Issue Type: New Feature Components: Other Affects Versions: 1.2.10 Reporter: Adam Davies Priority: Trivial Fix For: 1.2.10 Attachments: log4net - IP Address.zip Original Estimate: 0h Remaining Estimate: 0h Created AspNetIPAddressPatternConverter to provide the client IP Address. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-201) Add asynchronous logging behavior
[
https://issues.apache.org/jira/browse/LOG4NET-201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12767646#action_12767646
]
Ron Grabowski commented on LOG4NET-201:
---
Here's a ~50 line BufferingForwardingAppender inspired by Ayende:
public class AsyncBufferingForwardingAppender : BufferingForwardingAppender
{
private readonly object syncLock = new object();
private readonly LinkedListLoggingEvent[] eventsList = new
LinkedListLoggingEvent[]();
private bool anotherThreadAlreadyHandlesLogging;
public override void ActivateOptions()
{
base.ActivateOptions();
Fix = FixFlags.All ~FixFlags.LocationInfo;
}
// Rhino.Commons.Logging.AsyncBulkInsertAppender#SendBuffer
protected override void SendBuffer(LoggingEvent[] events)
{
ThreadPool.QueueUserWorkItem(delegate
{
lock (syncLock)
{
eventsList.AddLast(events);
if (anotherThreadAlreadyHandlesLogging)
{
return;
}
anotherThreadAlreadyHandlesLogging = true;
}
while (true)
{
LoggingEvent[] current;
lock (syncLock)
{
if(eventsList.Count == 0)
{
anotherThreadAlreadyHandlesLogging = false;
return;
}
current = eventsList.First.Value;
eventsList.RemoveFirst();
}
SynchronousSendBuffer(current);
});
}
protected virtual void SynchronousSendBuffer(LoggingEvent[] events)
{
foreach (AppenderSkeleton appender in Appenders)
{
appender.DoAppend(events);
}
}
}
Probably needs some flush code in the Close() method too.
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
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
[jira] Commented: (LOG4NET-225) Multithreading and Deadlocks
[ https://issues.apache.org/jira/browse/LOG4NET-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12767201#action_12767201 ] Ron Grabowski commented on LOG4NET-225: --- DRIN, the problem is that you shouldn't be logging from within appenders. Is that what your appender is doing? Multithreading and Deadlocks Key: LOG4NET-225 URL: https://issues.apache.org/jira/browse/LOG4NET-225 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Reporter: Thomas Haller Priority: Blocker Attachments: Log4NetDeadlock.zip If an Appender has to execute some logic on another thread, witch uses also log4net, this leads to a deadlock. The sample project i created demonstrates that problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Debugging log4net source
Tell me the exact nant command line to run and I'll run it. From: Omer Mor omer@gmail.com To: Log4NET Dev log4net-dev@logging.apache.org Sent: Sunday, August 23, 2009 11:49:03 AM Subject: Re: Debugging log4net source I would like to ask again the developer community of log4net for a signed build of 1.2.10 assembly that was compiled with a PDB file. This is the best way for us to enable live debugging of the log4net source. I believe it would only take a couple of minutes to compile it this way, and it would help us tremendously. Thanks again, Omer Mor (omer@gmail.com) On Fri, Aug 7, 2009 at 12:44 PM, Omer Mor omer@gmail.com wrote: I prefer debugging the situation live. Is it so hard to re-compile 1.2.10 with pdb? It's just a matter of a slight tweak in the project settings. On Fri, Aug 7, 2009 at 6:12 AM, Ron Grabowski rongrabow...@yahoo.com wrote: Have you tried specifying a custom error handler on the appender to track down when it enters a failed state? appender name=.. ... errorHandler type=Your.ErrorHandler, YourAssembly / /appender You would write one that sends an email when the file can't be created. From: Omer Mor omer@gmail.com To: log4net-dev@logging.apache.org Sent: Thursday, August 6, 2009 3:02:17 AM Subject: Debugging log4net source Hi, to research a (rare) bug we have with log4net (log file is not being created) we wanted to debug its source. However, the release build of 1.2.10 is supplied without a pdb file. And since it is a signed assembly we can't compile it ourself and replace it. Also - the debug build of 1.2.10 is supplied with a pdb, but is not signed, so it is not substitutable. What I'd like to ask is that one of the developers compile a release build of 1.2.10 and enable pdb creation, so that we could debug the source. Using a non-signed copy of log4net is not an option for us, because some of our 3rd-party assemblies are compiled against the signed 1.2.10 log4net assembly. The files could be sent irectly to me at omer@gmail.com . Thanks in advance, Omer Mor.
[jira] Commented: (LOG4NET-225) Multithreading and Deadlocks
[ https://issues.apache.org/jira/browse/LOG4NET-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12742149#action_12742149 ] Ron Grabowski commented on LOG4NET-225: --- Sounds like you have a general logging setup question not a locking issue. Maybe if you explain what you're trying to do (to the mail list) people might be able to help you configure your appenders correctly. Multithreading and Deadlocks Key: LOG4NET-225 URL: https://issues.apache.org/jira/browse/LOG4NET-225 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Reporter: Thomas Haller Priority: Blocker Attachments: Log4NetDeadlock.zip If an Appender has to execute some logic on another thread, witch uses also log4net, this leads to a deadlock. The sample project i created demonstrates that problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.
[ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12716776#action_12716776 ] Ron Grabowski commented on LOG4NET-27: -- Thanks for the patch! Is there anyway you can write the patch against the current revision in source control? There's been a number of largish pages since the 1.2.10 release. I haven't diff'ed the two files yet...maybe its just a simple copy paste of one or two methods and fixing wrapping the file IO calls to be called within the correct context like the calls to File.Move and File.Delete. I'm not sure I follow this code: else if (!byte.TryParse(current.Substring(charLoop, 1), out dummyByte)) Will that work if the numbers are not single digits: 10, .11, .12 ? I don't understand the need for PreviousCheckDate. Can't you determine the previous and current files by capturing the parameters to RollFile? None of the other file rolling code looks at the file system's date modified time...its all based on the filename. I wonder if this inconsistency will cause unexpected behavior. My idea was to change the signature of RollFile to return the name of the rolled file, create a list of rolled files, then iterate through that list and determine which of the new files are over the MaxDateRollBackups threshold and delete those files. I don't think it should take a lot of code to implement this functionality. Rolling files on date/time boundaries doesn't support a maximum number of backup files. --- Key: LOG4NET-27 URL: https://issues.apache.org/jira/browse/LOG4NET-27 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.11 Reporter: Florian Ramillien Priority: Minor Fix For: 1.2.11 Attachments: RollingFileAppender.cs, RollingFileAppender.cs.patch, RollingFileAppender.patch A maximum of backup files exist when rolling files on file size, but not for rolling on date/time. This can be implemented with the same config key : MaxSizeRollBackups -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed
I replaced the string.IsNullOrEmpty call with Length != 0 in StackTracePatternConverter.cs - Original Message From: carn...@apache.org carn...@apache.org To: log4net-dev@logging.apache.org Sent: Sunday, May 31, 2009 3:55:29 AM Subject: [g...@vmgump]: Project logging-log4net (in module logging-log4net) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project logging-log4net has an issue affecting its community integration. This issue affects 1 projects, and has been outstanding for 14 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - logging-log4net : Logging framework for .NET. Full details are available at: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/gump_work/build_logging-log4net_logging-log4net.html Work Name: build_logging-log4net_logging-log4net (Type: Build) Work ended in a state of : Failed Elapsed: 40 secs Command Line: NAnt.exe -D:java.awt.headless=true -D:gump.merge=/srv/gump/public/gump/work/merge.xml -D:build.sysclasspath=only -buildfile:log4net.build [Working Directory: /srv/gump/public/workspace/logging-log4net] DEVPATH: - check-doc-dir: check-sdkdoc-dir: check-sdkdoc-debug: check-current-build-config: check-build-debug: check-build-defines: set-mono-1.0-runtime-configuration: [property] Target framework changed to Mono 1.0 Profile. check-log4net-basedir: check-current-bin-dir: [mkdir] Creating directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. clean-current-bin-dir: [echo] Cleaning the bin/mono/1.0/debug binaries directory. [delete] Deleting directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. [mkdir] Creating directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. compile-mono-1.0: [csc] Compiling 215 files to '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug/log4net.dll'. [csc] /srv/gump/public/workspace/logging-log4net/src/Layout/Pattern/StackTracePatternConverter.cs(67,37): error CS0117: `string' does not contain a definition for `IsNullOrEmpty' [csc] Compilation failed: 1 error(s), 0 warnings BUILD FAILED - 0 non-fatal error(s), 1 warning(s) /srv/gump/public/workspace/logging-log4net/log4net.build(769,14): External Program Failed: /opt/mono/lib/pkgconfig/../../lib/mono/1.0/mcs.exe (return code was 1) Total time: 27.8 seconds. - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/rss.xml - Atom: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 3531052009, vmgump:vmgump-public:3531052009 Gump E-mail Identifier (unique within run) #2. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[jira] Created: (LOG4NET-216) Write a simple option parser for pattern converters
Write a simple option parser for pattern converters
---
Key: LOG4NET-216
URL: https://issues.apache.org/jira/browse/LOG4NET-216
Project: Log4net
Issue Type: New Feature
Components: Other
Affects Versions: 1.2.11
Reporter: Ron Grabowski
Priority: Minor
Fix For: 1.2.11
There isn't a standard way of passing in more than just a single value into
pattern converters:
%logger{2}
Create a simple parser that can split out the Option string:
public class RepeatConverter : PatternConverter
{
protected override void Convert(TextWriter writer, object state)
{
SimpleOptionParser optionParser = new SimpleOptionParser(Option);
char character = optionParser.GetChar(Character);
int repeat = optionParser.GetInt(Repeat, 1); // defaults to 1
writer.Write(new String(character, repeat));
}
}
Where the pattern might look something like this in the config file:
%repeat{Character:a,Repeat,10}
that would be translated into:
aa
Are there more established ways of encoding multiple values in a string?
%repeat{character:a;repeat:10}
%repeat{character=a:char,repeat=10:int}
???
Maybe this will allow the next next version of log4net to support nested
patterns...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-200) Log4Net Dll stops logging after 1 or 2 days
[ https://issues.apache.org/jira/browse/LOG4NET-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-200. --- Resolution: Cannot Reproduce There hasn't been any additional comments on this item since 2/2009. I'll finish out SendMailOnceErrorHandler and move that into the examples folder in svn. Log4Net Dll stops logging after 1 or 2 days --- Key: LOG4NET-200 URL: https://issues.apache.org/jira/browse/LOG4NET-200 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: IIS 6.0 Windows server 2003 (SP1) .Net Framework 2.0 Web Application Reporter: Christophe Chevalier Priority: Critical Fix For: v.Next Original Estimate: 96h Remaining Estimate: 96h Observation : The Log4Net service stops logging after 1 or 2 days Server reboot fixes the problem. IIS services reboot doesn't fix the problem. The internal debug mode doesn't give us any information, because of the problem is not reproductible. We use the RollingFileAppender and EventLogAppender classes. Have you any information about this (general) issue ? Thank you Regards -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-192) Memory leaks with large multi-threaded application in log4net DLL 1.2.0.30714
[ https://issues.apache.org/jira/browse/LOG4NET-192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-192. --- Resolution: Cannot Reproduce There hasn't been any additional posts on this item for several months after I asked for more information. Memory leaks with large multi-threaded application in log4net DLL 1.2.0.30714 - Key: LOG4NET-192 URL: https://issues.apache.org/jira/browse/LOG4NET-192 Project: Log4net Issue Type: Bug Environment: Windows 2003, .NET framework 1.1 Reporter: Vibha Kapur Priority: Critical We've coded log4net (1.2.0-beta8) into our application. With log4net enabled we see our virtual memory increasing and never decreasing, over a period of time and particularly with stress testing the server runs out of memory and everything grinds to a halt. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-207) Could not find schema information for the element 'log4net'
[
https://issues.apache.org/jira/browse/LOG4NET-207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ron Grabowski resolved LOG4NET-207.
---
Resolution: Invalid
This is a Visual Studio warning...not an error preventing your program from
running. Log4net's xml configuration processor sets properties on arbitrary
objects so its nearly impossible to express the structure of the document like
a conventional xml document.
Could not find schema information for the element 'log4net'
---
Key: LOG4NET-207
URL: https://issues.apache.org/jira/browse/LOG4NET-207
Project: Log4net
Issue Type: Bug
Affects Versions: 1.2.10
Environment: visual studio 2008 with .net 3.5
Reporter: ghinwa badawi
Priority: Blocker
Hi,
i have tried to use log4net in a windows service on VS2008 - .Net Framework:
3.5,
I added the following in the app.config file :
configSections
section name=log4net
type=log4net.Config.Log4NetConfigurationSectionHandler, log4net /
/configSections
log4net
appender name=FileAppender type=log4net.Appender.FileAppender
file value=C:\logfile.txt /
appendToFile value=true /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%date [%thread] %-5level %logger
[%property{NDC}] - %message%newline /
/layout
/appender
root
level value=DEBUG /
appender-ref ref=FileAppender /
/root
/log4net
but i am getting the below message:
Message5Could not find schema information for the element 'log4net'.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12712760#action_12712760
]
Ron Grabowski commented on LOG4NET-136:
---
My implementation attempts to convert the string type name into a real Type.
This will fail when the logs are shipped to another app domain that cannot load
the type. I'm investigating if
Spring.Core.TypeResolution.GenericArgumentsHolder (Apache license) might be
helpful. It parses the string without loading any Type information.
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.11
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.
-
You can reply to this email to add a comment to the issue online.
[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
]
Ron Grabowski updated LOG4NET-136:
--
Attachment: ConsoleApplication3-GenericPrettyPrinter.zip
Sample code to convert:
System.Collections.Generic.Dictionary`2[[System.Collections.Generic.Dictionary`2[[System.Collections.Generic.List`1[[System.Int32,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Collections.Generic.List`1[[System.String,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Collections.Generic.List`1[[System.String,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
into:
VB: Dictionary(Of Dictionary(Of List(Of Int32), List(Of String)), List(Of
String))
CS: DictionaryDictionaryListInt32, ListString, ListString
A better implementation might recursively parse the string instead of
converting the string back into a Type then back into a string...
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.11
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12712577#action_12712577
]
Ron Grabowski commented on LOG4NET-136:
---
I'm still surprised that I couldn't find example code that converts:
System.Collections.Generic.List`1[[System.Int32, mscorlib, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089]]
into:
VB: System.Collections.Generic.List(Of System.Int32)
CS: System.Collections.Generic.ListSystem.Int32
My implementation converts the string back into a Type and recurses through it:
private string recursiveGetShortTypeString(Type type, string openToken,
string closeToken)
{
// base case
string result = _displayTypeFullName ? type.FullName : type.Name;
if (type.IsGenericType)
{
// recursive case
result = result.Substring(0, result.IndexOf(GENERIC_TOKEN)) +
openToken;
Type[] genericArguments = type.GetGenericArguments();
for (int i = 0; i genericArguments.Length; i++)
{
Type genericArgument = genericArguments[i];
result += recursiveGetShortTypeString(genericArgument,
openToken, closeToken);
if (i != genericArguments.Length - 1)
{
result += GENERIC_SEPERATOR;
}
}
result += closeToken;
}
return result;
}
It handles complex generic objects:
System.Collections.Generic.Dictionary`2[[System.Collections.Generic.Dictionary`2[[System.Collections.Generic.List`1[[System.Int32,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Collections.Generic.List`1[[System.String,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral,
PublicKeyToken=b77a5c561934e089],[System.Collections.Generic.List`1[[System.String,
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]],
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]
VB: Dictionary(Of Dictionary(Of List(Of Int32), List(Of String)), List(Of
String))
CS: DictionaryDictionaryListInt32, ListString, ListString
I also converted the library into a converter
converter
name value=csLogger /
type
value=ConsoleApplication3_GenericPrettyPrinter.CSharpLoggerPatternConverter,
ConsoleApplication3-GenericPrettyPrinter /
/converter
public class CSharpLoggerPatternConverter : NamedPatternConverter
{
private readonly FullNameTypeConverter fullNameTypeConverter = new
FullNameTypeConverter(true);
protected override string GetFullyQualifiedName(LoggingEvent
loggingEvent)
{
return
fullNameTypeConverter.GetCSTypeString(loggingEvent.LoggerName);
}
}
that is based on the default LoggerPatternConverter (I made
NamedPatternConverter non-internal):
internal sealed class LoggerPatternConverter : NamedPatternConverter
{
override protected string GetFullyQualifiedName(LoggingEvent
loggingEvent)
{
return loggingEvent.LoggerName;
}
}
In theory you should be able to take advantage of the %logger{2} notation to
limit class depth.
I suspect its faster to parse the generic type string instead of converting the
string back into a Type. Will the Type always be loadable?
Is that what you had in mind?
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.11
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.
-
You can reply
Re: [GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed
This should be fixed. I forgot to commit the StackTracePatternConverter.cs file. - Original Message From: carn...@apache.org carn...@apache.org To: log4net-dev@logging.apache.org Sent: Sunday, May 24, 2009 7:49:41 PM Subject: [g...@vmgump]: Project logging-log4net (in module logging-log4net) failed To whom it may engage... This is an automated request, but not an unsolicited one. For more information please visit http://gump.apache.org/nagged.html, and/or contact the folk at gene...@gump.apache.org. Project logging-log4net has an issue affecting its community integration. This issue affects 1 projects. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - logging-log4net : Logging framework for .NET. Full details are available at: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -INFO- Failed with reason build failed The following work was performed: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/gump_work/build_logging-log4net_logging-log4net.html Work Name: build_logging-log4net_logging-log4net (Type: Build) Work ended in a state of : Failed Elapsed: 16 secs Command Line: NAnt.exe -D:java.awt.headless=true -D:gump.merge=/srv/gump/public/gump/work/merge.xml -D:build.sysclasspath=only -buildfile:log4net.build [Working Directory: /srv/gump/public/workspace/logging-log4net] DEVPATH: - check-doc-dir: check-sdkdoc-dir: check-sdkdoc-debug: check-current-build-config: check-build-debug: check-build-defines: set-mono-1.0-runtime-configuration: [property] Target framework changed to Mono 1.0 Profile. check-log4net-basedir: check-current-bin-dir: [mkdir] Creating directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. clean-current-bin-dir: [echo] Cleaning the bin/mono/1.0/debug binaries directory. [delete] Deleting directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. [mkdir] Creating directory '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug'. compile-mono-1.0: [csc] Compiling 214 files to '/srv/gump/public/workspace/logging-log4net/bin/mono/1.0/debug/log4net.dll'. [csc] /srv/gump/public/workspace/logging-log4net/src/Layout/PatternLayout.cs(863,72): error CS0246: The type or namespace name `StackTracePatternConverter' could not be found. Are you missing a using directive or an assembly reference? [csc] Compilation failed: 1 error(s), 0 warnings BUILD FAILED - 0 non-fatal error(s), 1 warning(s) /srv/gump/public/workspace/logging-log4net/log4net.build(769,14): External Program Failed: /opt/mono/lib/pkgconfig/../../lib/mono/1.0/mcs.exe (return code was 1) Total time: 7.9 seconds. - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/rss.xml - Atom: http://vmgump.apache.org/gump/public/logging-log4net/logging-log4net/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 14001624052009, vmgump:vmgump-public:14001624052009 Gump E-mail Identifier (unique within run) #1. -- Apache Gump http://gump.apache.org/ [Instance: vmgump]
[jira] Commented: (LOG4NET-55) Allow default null text,(null), and default not available text, NOT AVAILABLE, to be configurable.
[ https://issues.apache.org/jira/browse/LOG4NET-55?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708299#action_12708299 ] Ron Grabowski commented on LOG4NET-55: -- Don't you want to know when something that's suppose to be there is missing? I suppose there are times when one doesn't... Can you give an example of when you'd use this? I could go either way on this. Allow default null text,(null), and default not available text, NOT AVAILABLE, to be configurable. -- Key: LOG4NET-55 URL: https://issues.apache.org/jira/browse/LOG4NET-55 Project: Log4net Issue Type: Improvement Reporter: Ron Grabowski Assignee: Ron Grabowski Priority: Trivial Fix For: 1.2.10 Attachments: ConfigurableNullTextAndNotAvailableText.patch, ConfigurableNullTextAndNotAvailableText2.patch (null) and NOT AVAILABLE are not settable by the user. Allow them to be settable via AppSettings keys: add key=log4net.NullText value=NULL-TEXT / add key=log4net.NotAvailableText value=NOT-AVAILABLE-TEXT / or attributes on the log4net node: log4net nullText=NULL-TEXT notAvailableText=NOT-AVAILABLE-TEXT ... /log4net or in code: log4net.Util.SystemInfo.NullText = NULL-TEXT; log4net.Util.SystemInfo.NotAvailableText = NOT-AVAILABLE-TEXT; -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: all the example files are missing from the log4net website
The following examples are only available in the log4net release download, not on-line. To obtain the examples download one of the log4net releases. - Original Message From: Johan Compen joh...@gmail.com To: log4net-dev@logging.apache.org Sent: Tuesday, March 31, 2009 9:38:03 AM Subject: all the example files are missing from the log4net website All links on this page are dead: http://logging.apache.org/log4net/release/example-apps.html Not Found The requested URL /examples/net/1.0/Tutorials/ConsoleApp/cs was not found on this server.
[jira] Commented: (LOG4NET-20) [PATCH] Adds extends attribute to appenders
[
https://issues.apache.org/jira/browse/LOG4NET-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12683250#action_12683250
]
Ron Grabowski commented on LOG4NET-20:
--
How about this syntax?
appender name=FileAppender1 type=log4net.Appender.RollingFileAppender
configuration-ref name=RollingFileConfig /
configuration-ref name=ConversionPatternConfig /
param name=File value=log1.txt/
/appender
appender name=FileAppender2 type=log4net.Appender.RollingFileAppender
configuration-ref name=RollingFileConfig /
file value=log2.txt/
layout type=log4net.Layout.SimpleLayout /
/appender
appender name=FileAppender3 type=log4net.Appender.RollingFileAppender
configuration-ref name=RollingFileConfig /
configuration-ref name=ConversionPatternConfig /
file value=log3.txt/
/appender
configuration name=RollingFileConfig
param name=CountDirection value=1/
param name=AppendToFile value=true/
param name=MaxSizeRollBackups value=10/
maximumFileSize value=5MB/
rollingStyle value=Size/
staticLogFileName value=true/
/configuration
configuration name=ConversionPatternConfig
layout type=log4net.Layout.PatternLayout
param name=ConversionPattern value=%d{dd.MM.yy HH:mm:ss} [%t] %-5p %c{1}
%m [%x]%n/
/layout
/configuration
[PATCH] Adds extends attribute to appenders
-
Key: LOG4NET-20
URL: https://issues.apache.org/jira/browse/LOG4NET-20
Project: Log4net
Issue Type: Improvement
Components: Appenders
Affects Versions: 1.2.9
Environment: WinXP, .NET Framework 1.1
Reporter: Dag Christensen
Priority: Trivial
Attachments: DOMHierarchyConfigurator.patch
Adds extends attribute to appenders. Improvement suggested by Ron Grabowski
on log4net-user.
Sample usage:
appender name=LogFileAppenderBase
type=log4net.Appender.RollingFileAppender
param name=CountDirection value=1/
param name=AppendToFile value=true/
param name=MaxSizeRollBackups value=10/
param name=MaximumFileSize value=5MB/
param name=RollingStyle value=Size/
param name=StaticLogFileName value=true/
/appender
appender name=LogFileAppenderDefaultLayout extends=LogFileAppenderBase
layout type=log4net.Layout.PatternLayout
param name=ConversionPattern value=%d{dd.MM.yy HH:mm:ss}
[%t] %-5p %c{1} %m [%x]%n/
/layout
/appender
appender name=LogFileAppender extends=LogFileAppenderDefaultLayout
param name=File value=log.txt/
/appender
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-186) PatternLayout and globalRulesRegistry
[
https://issues.apache.org/jira/browse/LOG4NET-186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682357#action_12682357
]
Ron Grabowski commented on LOG4NET-186:
---
I believe you're highlighting the verboseness of reusing a converter across
multiple parameters:
parameter
parameterName value=@password /
dbType value=String /
layout type=log4net.Layout.PatternLayout
converter
name value=encrypt /
type value=Company.Logging.EncryptConverter, Company.Logging /
/converter
conversionPattern value=%encrypt{Password} /
/layout
/parameter
parameter
parameterName value=@creditCardNumber /
dbType value=String /
layout type=log4net.Layout.PatternLayout
converter
name value=encrypt /
type value=Company.Logging.EncryptConverter, Company.Logging /
/converter
conversionPattern value=%encrypt{CreditCardNumber} /
/layout
/parameter
Exposing s_globalRulesRegistry might help from a code perspective but it isn't
going to help with the more typical XML configuration. Your idea of specifying
the converter once and reusing it across all parameters makes sense. While
we're at it, lets take out some of the verboseness of having to specify the
PatternLayout:
converter
name value=encrypt /
type value=Company.Logging.EncryptConverter, Company.Logging /
/converter
patternLayoutParameter
parameterName value=@password/
dbType value=String /
conversionPattern value=%encrypt{Password} /
/patternLayoutParameter
patternLayoutParameter
parameterName value=@creditCardNumber/
dbType value=String /
conversionPattern value=%encrypt{CreditCardNumber} /
/patternLayoutParameter
To support that syntax I've extending AdoNetAppender to capture the converter
items:
public class PatternLayoutAdoNetAppender : AdoNetAppender
{
private readonly ListConverterInfo converters = new
ListConverterInfo();
public void AddConverter(ConverterInfo converterInfo)
{
converters.Add(converterInfo);
}
}
I also extended AdoNetAppenderParameter with a class that accepts a
conversionPattern:
public class PatternLayoutAdoNetAppenderParameter :
AdoNetAppenderParameter
{
private string conversionPattern;
public string ConversionPattern
{
get { return conversionPattern; }
set { conversionPattern = value; }
}
}
This last snippet of code wires up the patternLayoutParameter / nodes. It
takes the conversionPattern value and converts it into a format that the
AdoNetAppender understands:
public void
AddPatternLayoutParameter(PatternLayoutAdoNetAppenderParameter parameter)
{
PatternLayout patternLayout = new
PatternLayout(parameter.ConversionPattern);
addConveters(patternLayout);
patternLayout.ActivateOptions();
parameter.Layout = new Layout2RawLayoutAdapter(patternLayout);
m_parameters.Add(parameter);
}
private void addConveters(PatternLayout patternLayout)
{
foreach (ConverterInfo conveterInfo in converters)
{
patternLayout.AddConverter(conveterInfo);
}
}
You can also mix and match patternLayoutParameter / and parameter / nodes.
I'll add the complete class with some test cases to the example appender area
in /trunk.
PatternLayout and globalRulesRegistry
-
Key: LOG4NET-186
URL: https://issues.apache.org/jira/browse/LOG4NET-186
Project: Log4net
Issue Type: Improvement
Components: Core
Affects Versions: 1.2.10
Reporter: Sergey
Original Estimate: 0.17h
Remaining Estimate: 0.17h
Hi, i have suggestion.
Make for private static field PatternLayout.s_globalRulesRegistry public
static accessor. Because if i want append custom PatternLayoutConverter, i
need add him to each PatternLayout for each Appender.
I am using AdoNetAppender, which creates PatternLayout for each parameter.
And i must append my PatternLayoutConverter to each param. I think, if i have
static property or method for adding PatternLayoutConvertor - its will be
more simple for use.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-180) SMTPAppender not sending all emails
[
https://issues.apache.org/jira/browse/LOG4NET-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682365#action_12682365
]
Ron Grabowski commented on LOG4NET-180:
---
It sounds like a server issue. Have you tried enabling SmtpClient's internal
debugging:
Griping about System.Net.Email.SmptClient/MailMessage
http://www.west-wind.com/weblog/posts/229457.aspx
or writing your own SmtpAppender that sends mail? SmtpAppender.SendEmail just
creates an SmtpClient, sets properties, then calls Send(MailMessage).
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
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-193) Supported Frameworks Inconsistency on Website
[ https://issues.apache.org/jira/browse/LOG4NET-193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-193. --- Resolution: Fixed Fixed in r754496. Made the two lists consistent. Supported Frameworks Inconsistency on Website - Key: LOG4NET-193 URL: https://issues.apache.org/jira/browse/LOG4NET-193 Project: Log4net Issue Type: Bug Components: Documentation Environment: Firefox 3.0.5 Reporter: Ryan Schlesinger Original Estimate: 0.17h Remaining Estimate: 0.17h Viewing the list of supported frameworks on http://logging.apache.org/log4net/release/manual/introduction.html states that log4net does not support .NET 2 and does support Compact Framework 2. Viewing the list of supported frameworks on http://logging.apache.org/log4net/release/framework-support.html states that log4net does indeed support .NET 2 and does not list support for Compact Framework 2. After downloading 1.2.10 and inspecting the bin directory, it appears that the second page is correct and the introduction in the manual needs to be corrected. This seems like a major documentation issue as that is the starting point for many at the site who may be looking for .NET 2.0 support. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-189) XmlConfigurator.Configure(Stream) needs a a Stream with pointer at beginning
[ https://issues.apache.org/jira/browse/LOG4NET-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-189. --- Resolution: Won't Fix I haven't heard any additional discussions why we should change the current behavior so I'm resolving this item. Log4net will continue to process the Stream based on the position that is passed in. XmlConfigurator.Configure(Stream) needs a a Stream with pointer at beginning Key: LOG4NET-189 URL: https://issues.apache.org/jira/browse/LOG4NET-189 Project: Log4net Issue Type: Improvement Reporter: Maik Priority: Trivial Is it possible to set the stream for configuring log4net to the beginning of the stream by default? In my application I created my own MemoryStream with an XML-Configuration for log4net. Trying to call XmlConfigurator.Configure(myStream), I got an Exeption of the type System.Xml.XmlException: Missing Root-Element. Setting the StreamPointer to the beginning by calling myStream.Seek(0, SeekOrigin.Begin); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-188) RollingFileAppender log.1, log.2 are not being rolled by Date
[ https://issues.apache.org/jira/browse/LOG4NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-188. --- Resolution: Cannot Reproduce You mentioned the rolling works fine in one project but not the other which leads me to believe that there is a problem with your configuration. There have been improvements to the RollingFileAppender. Try running your code against the latest versison and re-open this ticket if you're still having issues. RollingFileAppender log.1, log.2 are not being rolled by Date - Key: LOG4NET-188 URL: https://issues.apache.org/jira/browse/LOG4NET-188 Project: Log4net Issue Type: Bug Components: Appenders Environment: .NET 2005, Microsoft Windows Server 2003 Reporter: Gulden Yazgan Fix For: 1.2.10 I am using log4net.dll v1.2.0.30714. My RollingFileAppender rolls only the .log file every day but ignores the log.1, log.2 etc... This is only happening on my Web Service. My Windows Service project does not have this problem. It works fine with the same log4net.dll version. I credted the log4net.txt. I am attaching a section of it below: Note: By looking at the RollingFileAppeder.cs, If StaticLogFileName=true, it is from a different date period should not appear. Am I wrong on this? log4net: DOMConfigurator: Loading Appender [RollingLogFileAppender] type: [log4net.Appender.RollingFileAppender] log4net: DOMConfigurator: Setting Property [File] to String value [D:\Apps\Agents\GFS\Strategyware\EnterpriseMQServices\Logs\Activity.log] log4net: DOMConfigurator: Setting Property [AppendToFile] to Boolean value [True] log4net: DOMConfigurator: Setting Property [DatePattern] to String value [.MM-dd-.log] log4net: DOMConfigurator: Setting Property [RollingStyle] to RollingMode value [Composite] log4net: DOMConfigurator: Setting Property [MaxSizeRollBackups] to Int32 value [20] log4net: DOMConfigurator: Setting Property [MaximumFileSize] to String value [15MB] log4net: DOMConfigurator: Setting Property [StaticLogFileName] to Boolean value [True] log4net: DOMConfigurator: Setting Property [ConversionPattern] to String value [%d [%t] %-5p %c [%x] - %m%n] log4net: DOMConfigurator: Setting Property [Layout] to object [log4net.Layout.PatternLayout] log4net: RollingFileAppender: Type = [0], r0 = [.12-31-1969.log], r1 = [.12-31-1969.log] log4net: RollingFileAppender: Type = [1], r0 = [.12-31-1969.log], r1 = [.12-31-1969.log] log4net: RollingFileAppender: Type = [2], r0 = [.12-31-1969.log], r1 = [.01-01-1970.log] log4net: RollingFileAppender: Searching for existing files in [D:\Apps\Agents\GFS\Strategyware\EnterpriseMQServices\Logs] log4net: RollingFileAppender: Ignoring file [activity.log.1] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.2] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.3] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.4] because it is from a different date period -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-202) AdoNetAppenderParameter.Size Property is not optional
[ https://issues.apache.org/jira/browse/LOG4NET-202?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682055#action_12682055 ] Ron Grabowski commented on LOG4NET-202: --- Have you tried using SqlDbType.Text and/or a size of -1? http://stackoverflow.com/questions/596257/what-sqldbtype-maps-to-varcharmax AdoNetAppenderParameter.Size Property is not optional - Key: LOG4NET-202 URL: https://issues.apache.org/jira/browse/LOG4NET-202 Project: Log4net Issue Type: Bug Components: Documentation Affects Versions: 1.2.10 Environment: Windows Server 2008, .NET 3.5 SP1, SQL Server 2008 Reporter: Richard Dingwall Original Estimate: 0.5h Remaining Estimate: 0.5h The AdoNetAppenderParameter.Size page (http://logging.apache.org/log4net/release/sdk/log4net.Appender.AdoNetAppenderParameter.Size.html) says This property is optional. If not specified the ADO.NET provider will attempt to infer the size from the value. However, I just got the following exception in the log4net internal debug trace, with the following parameter (maps to a VARCHAR(MAX)): parameter parameterName value=@exception / dbType value=String / layout type=log4net.Layout.ExceptionLayout / /parameter log4net:ERROR [AdoNetAppender] Could not prepare database command [INSERT INTO ] System.InvalidOperationException: SqlCommand.Prepare method requires all variable length parameters to have an explicitly set non-zero Size. at System.Data.SqlClient.SqlParameter.Prepare(SqlCommand cmd) at System.Data.SqlClient.SqlCommand.Prepare() at log4net.Appender.AdoNetAppender.InitializeDatabaseCommand() This would suggest the Size parameter cannot be null. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12682063#action_12682063 ] Ron Grabowski commented on LOG4NET-197: --- Here are my wget debug logs from a computer in Colorado (western United States) and Ohio (eastern United States): Connecting to archive.apache.org:80... Caching archive.apache.org - 192.87.10.226 ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sat, 14 Mar 2009 15:57:22 GMT Server: Apache/2.2.9 (Unix) Last-Modified: Sun, 30 Dec 2007 19:43:36 GMT ETag: 14890-7d2d38-4428624b90a00 Accept-Ranges: bytes Content-Length: 8203576 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/zip Found archive.apache.org in host_name_address_map: 192.87.106.226 Registered fd 1948 for persistent reuse. Length: 8,203,576 [application/zip] 0K .. .. .. .. .. 0% @ 49.21 KB/s 50K .. .. .. .. .. 1% @ 82.10 KB/s 100K .. .. .. .. .. 1% @ 81.97 KB/s [snip] 4650K .. .. .. .. .. 58% @ 78.00 KB/s 4700K .. .. .. .. .. 59% @ 24.62 KB/s 4750K .. .. .. .. .. 59% @ 34.79 KB/s 4800K 60% @ 42.55 KB/s 11:58:58 (51.79 KB/s) - Connection closed at byte 4923392. Retrying. And then from a computer in Ohio: Caching archive.apache.org = 192.87.106.226 Connecting to archive.apache.org|192.87.106.226|:80... seconds 0.00, connected. ---request end--- HTTP request sent, awaiting response... ---response begin--- HTTP/1.1 200 OK Date: Sat, 14 Mar 2009 16:05:47 GMT Server: Apache/2.2.9 (Unix) Last-Modified: Sun, 30 Dec 2007 19:43:36 GMT ETag: 14890-7d2d38-4428624b90a00 Accept-Ranges: bytes Content-Length: 8203576 Keep-Alive: timeout=5, max=100 Connection: Keep-Alive Content-Type: application/zip ---response end--- 200 OK Registered socket 1940 for persistent reuse. Length: 8,203,576 (7.8M) [application/zip] 100%[] 8,203,576 1.86M/sETA 00:00 12:05:52 (1.68 MB/s) - `incubating-log4net-1.2.10.zip' saved [8203576/8203576] It looks like 192.87.106.226 works correctly while 192.87.10.226 does not. Is everyone getting errors at 4923392? 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-196) Remote Logging Stuff doesn't seem to have anyway to work between AppDomains
[ https://issues.apache.org/jira/browse/LOG4NET-196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682070#action_12682070 ] Ron Grabowski commented on LOG4NET-196: --- Can you give a better example of what you think needs changed? Remote Logging Stuff doesn't seem to have anyway to work between AppDomains --- Key: LOG4NET-196 URL: https://issues.apache.org/jira/browse/LOG4NET-196 Project: Log4net Issue Type: Bug Reporter: Jerome Haltom There's no way to obtain a proper url to a IRemoteLoggignSink that ends up being published in the local app domain. There needs to be a way to set the IRemoteLoggingSink instance specifically, managing the remoting yourself. This would solve it easily. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-195) Log4Net Performance comparison with other logging utility
[ https://issues.apache.org/jira/browse/LOG4NET-195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-195. --- Resolution: Later Thanks for the discussion. There will eventually be an async appender in log4net. If you have specific questions about log4net performance the discussion lists are a better place to talk. Log4Net Performance comparison with other logging utility - Key: LOG4NET-195 URL: https://issues.apache.org/jira/browse/LOG4NET-195 Project: Log4net Issue Type: Test Affects Versions: 1.2.10 Environment: .Net Framework 2.0, VS 2005, Windows XP Reporter: Ashish Khandelwal Priority: Critical Attachments: Log4Net_Vs_nSpring.zip I developed one utility to compare the performance between Log4Net and nSpring(another logging utility). The result I saw is surprise to me - Log4Net took more time than nSpring. It is surprise because Log4net claims to be fast and flexible: speed first, flexibility second. Log4Net says: (http://logging.apache.org/log4net/release/manual/internals.html) One of the often-cited arguments against logging is its computational cost. This is a legitimate concern as even moderately sized applications can generate thousands of log requests. Much effort was spent measuring and tweaking logging performance. Log4net claims to be fast and flexible: speed first, flexibility second. Although test is saying Log4Net takes more time, I am still not convinced with the result achieved, considering the fact; Log4Net is widely accepted by the industry and known for its speed, reliability and flexibility. I would like to know why Log4Net is taking more time, we might be missing any setting or other which can boost the performance. Can you please help to know the reason? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-194) FileSystemWatcher for .Net Compact Framework
[ https://issues.apache.org/jira/browse/LOG4NET-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12682072#action_12682072 ] Ron Grabowski commented on LOG4NET-194: --- How can I test this on a Windows XP, VS2005/2008 box? Can I build the project using nant then execute a test program using the Compact Framework runtime? 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 Attachments: log4netcf.vs2008.dll, log4netcf.vs2008_20090210.zip, Log4NetTest_20090210.zip, Modified_Files_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. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (LOG4NET-146) System.NullReferenceException on FindAndRender object
[ https://issues.apache.org/jira/browse/LOG4NET-146?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski resolved LOG4NET-146. --- Resolution: Cannot Reproduce I took a look at DefaultRenderer and it looks like the appropriate null checks are in place. Open another ticket if you, or someone else, can provide more information what was being rendered. System.NullReferenceException on FindAndRender object - Key: LOG4NET-146 URL: https://issues.apache.org/jira/browse/LOG4NET-146 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows 2003 Server Release 2 Oracle ODP Version (Oracle.DataAccess.dll) 1.102.3.0 .Net 1.1.4332 Reporter: Matthias Krause Fix For: 1.2.11 Get following error text: log4net.ErrorException rendering object type [System.NullReferenceException]stackTraceSystem.NullReferenceException: Object reference not set to an instance of an object. at System.Diagnostics.StackTrace.GetStackFramesInternal(StackFrameHelper sfh, Int32 iSkip, Exception e) at System.Diagnostics.StackTrace.CaptureStackTrace(Int32 iSkip, Boolean fNeedFileInfo, Thread targetThread, Exception e) at System.Diagnostics.StackTrace..ctor(Exception e, Boolean fNeedFileInfo) at System.Environment.GetStackTrace(Exception e) at System.Environment.GetStackTrace(Exception e) at System.Exception.get_StackTrace() at System.Exception.ToString() at System.Exception.ToString() at log4net.ObjectRenderer.DefaultRenderer.RenderObject(RendererMap rendererMap, Object obj, TextWriter writer) at log4net.ObjectRenderer.RendererMap.FindAndRender(Object obj, TextWriter writer)/stackTrace/log4net.Error Exception come form a OracleDataAdapter Fill call from a C# application. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: turn up/down message details
Log4net doesn't have anything built-in to support that. One strategy might be to keep the logger / at DEBUG and set the appender /'s threshold to WARN. If the number of warnings overflows some allowable level, you could change that appender /'s threshold to INFO for a certain amount of time then bump it back up to WARN. In situations like this is sometimes helpful to see if there is log4j appender that does something similiar. Sometimes they have interesting appenders in their trunk or branches. - Original Message From: rodchar rodc...@hotmail.com To: log4net-dev@logging.apache.org Sent: Sunday, February 22, 2009 12:11:45 PM Subject: turn up/down message details hey all, is there a way to throttle up/down the verboseness of a log message? for instance, low details when application is running fine, high details when there's a problem and need to debug? thanks, rodchar -- View this message in context: http://www.nabble.com/turn-up-down-message-details-tp22149036p22149036.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
[jira] Issue Comment Edited: (LOG4NET-201) Add asynchronous logging behavior
/ /root would be changed to: root appender-ref ref=AsyncForwardingAppender / /logger where the appender could have all sorts of other options like UseThreadPool, UseCustomThreadPool, etc. and whose configurations could be much better defined by the existing xml processor: appender name=AsyncForwardingAppender type=... useThreadPool value=false threadPool threadCountMatchesAppenderCount value=true / dispatchMode value=concurrent / /threadPool fixFlag value=All / maxQueuedItems value=500 / forceFlushOn value=WARN / asyncEnabled value=true / flushBufferInterval value=6 / appender-ref ref=MyFileAppender / appender-ref ref=MyAdoNetAppender / appender / If you extended AppenderSkeleton you could take advantage of things like IErrorHandler and Filters. Current log4net users could immediately take advantage of a robust async appending that itself queues items them dispatches them to one or more attached appenders. In fact a poor man's async appender already exists...put a BufferingForwardingAppender in front of this AsyncAppender: http://svn.apache.org/viewvc/logging/log4net/trunk/examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender/ and you can happily batch process buffered entries using the ThreadPool. Here's another example of very high performant buffering async appender for Sql Server: http://rhino-tools.svn.sourceforge.net/viewvc/rhino-tools/trunk/commons/Rhino.Commons/Logging/ Those extensions occurred without having to change the library itself. A good async forwarding appender would allow async functionality to automatically be added to all the existing appenders like EventLogAppender, LocalSysLogAppender, FileAppender, etc. If you want to go crazy with the async stuff I suppose you could dispatch the LoggingEvent immediately after it was created/Fixed so the routing stuff occurs on a different thread which also dispatches the messages to the appenders. I'd think about creating a custom ILoggerRepository at that point. 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 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
Re: log definition is in my pagebase
The simplest solution is to use a logger per class instead of one shared logger. - Original Message From: rodchar rodc...@hotmail.com To: log4net-dev@logging.apache.org Sent: Friday, February 20, 2009 10:54:25 AM Subject: log definition is in my pagebase Hi all, i have a pagebase class where all my tiers inherit from. i'm using the fileappender and i noticed the logger says it came from pagebase. is there a way to tell it to report the inheriting class that actually logged the record? thanks, rodchar -- View this message in context: http://www.nabble.com/log-definition-is-in-my-pagebase-tp22120458p22120458.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
Re: log4net event logging appender
When you run your program as a normal user can you write to the EventLog without using log4net? - Original Message From: rodchar rodc...@hotmail.com To: log4net-dev@logging.apache.org Sent: Wednesday, February 18, 2009 4:45:22 PM Subject: log4net event logging appender http://www.nabble.com/file/p22088962/log4tester.PNG log4tester.PNG hi all, i have the simplest console app to test the eventlog appender. http://www25.brinkster.com/rodchar/log4net.htm image of windiff Initially, if i run the app as a user the event log won't work. However, if i run the app as an admin, it successfully writes to the event log. Then when i run the app again as a user it will log to the event log (unlike before). can someone please explain this? Console Messages: * Run As User * log4net:ERROR DOMConfigurator: Could not create Appender [EventLogAppender] of t ype [log4net.Appender.EventLogAppender]. Reported error follows. System.Security.SecurityException: The source was not found, but some or all eve nt logs could not be searched. Inaccessible logs: Security. at System.Diagnostics.EventLog.FindSourceRegistration(String source, String m achineName, Boolean readOnly) at System.Diagnostics.EventLog.SourceExists(String source, String machineName ) at System.Diagnostics.EventLog.SourceExists(String source) at log4net.Appender.EventLogAppender.ActivateOptions() at log4net.Repository.Hierarchy.DOMHierarchyConfigurator.ParseAppender(XmlEle ment appenderElement) The Zone of the assembly that failed was: MyComputer log4net:ERROR DOMConfigurator: Appender named [EventLogAppender] not found. * Run As Admin * log4net: EventLogAppender: Creating event source Source [log4netTester.exe] in l og Application] log4net: EventLogAppender: Source [log4netTester.exe] is registered to log [Appl ication] log4net: DOMConfigurator: Created Appender [EventLogAppender] log4net: DOMConfigurator: Adding appender named [EventLogAppender] to logger [ro ot]. thanks, rodchar -- View this message in context: http://www.nabble.com/log4net-event-logging-appender-tp22088962p22088962.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
Re: Commit access requested for an asynchronous logging addition
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 jaub...@connamara.com To: log4net-dev@logging.apache.org 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. There are unit tests for the new code. Jason Aubrey
[jira] Commented: (LOG4NET-199) log4net not exactly threadsafe?
[ https://issues.apache.org/jira/browse/LOG4NET-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12674086#action_12674086 ] Ron Grabowski commented on LOG4NET-199: --- The current release of log4net has been out for a couple years now. I'm sure someone would have noticed by now if it was failing with just 2 threads. log4net not exactly threadsafe? --- Key: LOG4NET-199 URL: https://issues.apache.org/jira/browse/LOG4NET-199 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows Server 2003 Reporter: Kenneth Shih Problem: We call log4net from our BizTalk 2006 orchestrations. We noticed we were missing logging data. Doing a simple Nunit single threaded test, we would get all logged data. (repeatable) In a Nunit multithreaded test, we would notice missed logged data. (repeatable) Also, we also noticed when BizTalk Host, when we lowered the amount of active threads down to 2 (the lowest we could go) So, We enabled debug tracing in log4net. We also added various system.diag eventlogwrites around different parts of our code, from where log4net was called, and also inside our appenders. We noticed was saw an error in the debug tracing (using debugviewer) log4net:ERROR [EventLogAppender] Attempted to append to closed appender named [EventLogAppender]. Also, by counting the number of eventlog entries we had from the various points, log4net itself was not calling the appenders each time it was called to log a message. We seen this issue of log4net not calling the appenders, with a variety of different appenders, like the out of the box file and eventlog appenders and also our own msmq appender. So log4net doesn't appear to be thread safe? Any suggestions? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (LOG4NET-199) log4net not exactly threadsafe?
[ https://issues.apache.org/jira/browse/LOG4NET-199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski updated LOG4NET-199: -- Attachment: ThreadingTest.cs The attached file uses 50 threads to write to 5 StringAppenders for 30 seconds. The StringAppenders all match at the end. Let me know if this is similar to what you tested and/or how I can change the test case to make it more accurate. log4net not exactly threadsafe? --- Key: LOG4NET-199 URL: https://issues.apache.org/jira/browse/LOG4NET-199 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows Server 2003 Reporter: Kenneth Shih Attachments: ThreadingTest.cs Problem: We call log4net from our BizTalk 2006 orchestrations. We noticed we were missing logging data. Doing a simple Nunit single threaded test, we would get all logged data. (repeatable) In a Nunit multithreaded test, we would notice missed logged data. (repeatable) Also, we also noticed when BizTalk Host, when we lowered the amount of active threads down to 2 (the lowest we could go) So, We enabled debug tracing in log4net. We also added various system.diag eventlogwrites around different parts of our code, from where log4net was called, and also inside our appenders. We noticed was saw an error in the debug tracing (using debugviewer) log4net:ERROR [EventLogAppender] Attempted to append to closed appender named [EventLogAppender]. Also, by counting the number of eventlog entries we had from the various points, log4net itself was not calling the appenders each time it was called to log a message. We seen this issue of log4net not calling the appenders, with a variety of different appenders, like the out of the box file and eventlog appenders and also our own msmq appender. So log4net doesn't appear to be thread safe? Any suggestions? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-199) log4net not exactly threadsafe?
[ https://issues.apache.org/jira/browse/LOG4NET-199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673130#action_12673130 ] Ron Grabowski commented on LOG4NET-199: --- In a Nunit multithreaded test, we would notice missed logged data. (repeatable) Can you attach the failing tests to this ticket? log4net not exactly threadsafe? --- Key: LOG4NET-199 URL: https://issues.apache.org/jira/browse/LOG4NET-199 Project: Log4net Issue Type: Bug Components: Core Affects Versions: 1.2.10 Environment: Windows Server 2003 Reporter: Kenneth Shih Problem: We call log4net from our BizTalk 2006 orchestrations. We noticed we were missing logging data. Doing a simple Nunit single threaded test, we would get all logged data. (repeatable) In a Nunit multithreaded test, we would notice missed logged data. (repeatable) Also, we also noticed when BizTalk Host, when we lowered the amount of active threads down to 2 (the lowest we could go) So, We enabled debug tracing in log4net. We also added various system.diag eventlogwrites around different parts of our code, from where log4net was called, and also inside our appenders. We noticed was saw an error in the debug tracing (using debugviewer) log4net:ERROR [EventLogAppender] Attempted to append to closed appender named [EventLogAppender]. Also, by counting the number of eventlog entries we had from the various points, log4net itself was not calling the appenders each time it was called to log a message. We seen this issue of log4net not calling the appenders, with a variety of different appenders, like the out of the box file and eventlog appenders and also our own msmq appender. So log4net doesn't appear to be thread safe? Any suggestions? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Appender Close() not being called when application ends
The static constructor on LogManager calls ShutDown in the AppDomain's ProcessExit and DomainUnload: // ProcessExit seems to be fired if we are part of the default domain AppDomain.CurrentDomain.ProcessExit += new EventHandler(OnProcessExit); // Otherwise DomainUnload is fired AppDomain.CurrentDomain.DomainUnload += new EventHandler(OnDomainUnload); - Original Message From: Michael Mayne mich...@michaelmayne.me.uk To: Log4NET Dev log4net-dev@logging.apache.org Sent: Tuesday, February 10, 2009 12:43:42 AM Subject: RE: Appender Close() not being called when application ends Hi, It would be great if someone - anyone - could give me some feedback on this. Perhaps it's a bug that log4net doesn't appear to close loggers before it is garbage collected? Thanks Michael Mailing list archives Site index · List index Message view « Date » · « Thread » Top « Date » · « Thread » From Michael Mayne mich...@michaelmayne.me.uk Subject Appender Close() not being called when application ends Date Fri, 06 Feb 2009 09:50:56 GMT Hi, I'm creating a custom AsyncAppender() that buffers synchronous event appends , using an internal dequeue thread to process these buffered events sending them onto attached appenders. The internal workings are not important to my problem (I think)... What I'm seeing is that neither the Close() or ~AsyncAppender() (finalize) methods are being called when my test program attempts to exit i.e. my test program hangs. This is important because my class cleanup triggers the dequeue thread to drain any buffered events, terminate the thread and dispose. If not triggered the dequeue thread sits there waiting on an autoReset event for ever - hence the program hang. However, If I explicitly shutdown the repository, Close() is called and it all works perfectly. logger.Logger.Repository.Shutdown(); AsyncAppender inherits AppenderSkeleton so overrides OnClose(). It also implements IDisposable using the classic Dispose pattern. My test program is configuring everything programmatically (no config files) so I can see what's going on - well that was the idea J I would have thought that when my program exited, Log4net would be garbage collected and my Close() (or destructor) method would be called. What am I doing wrong? I can include some code later but I really want to get an idea of the appender lifecycle. Thanks Michael Mime Unnamed multipart/alternative (inline, None, 0 bytes) Unnamed text/plain (inline, 7-Bit, 1380 bytes) Unnamed text/html (inline, Quoted Printable, 4099 bytes) View raw message -Original Message- From: Lukasz Antoniak (JIRA) [mailto:j...@apache.org] Sent: 09 February 2009 23:52 To: log4net-dev@logging.apache.org Subject: [jira] Commented: (LOG4NET-194) FileSystemWatcher for .Net Compact Framework [ https://issues.apache.org/jira/browse/LOG4NET-194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12672064#action_12672064 ] Lukasz Antoniak commented on LOG4NET-194: - Welcome again! I have spent some time developing FileSystemWatcher class, and I wanted to share my results. In the attachment I submit several things: 1)Classes that I have modified or added (XmlConfigurator.cs, FileSystemWatcher.cs, FileSystemEventArgs.cs and RenamedEventArgs). 2)The compiled assembly (debug). 3)The whole Log4Net project (for MS Visual 2008). I have added classes mentioned above to Util/FileSystemWatcher folder. 4)The simple test case project. The test works as follows: When the application starts, the new Log4Net configuration file is being created and 2 messages logged. The form provides two buttons. The first one Log logs messages, and the second Change modifies the configuration file, so that the log messages are saved to a different location (look in the application directory in Program Files folder). Is there any possibility to add those changes in next Log4Net release? Regards, Lukasz Antoniak 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 Attachments: log4netcf.vs2008.dll, log4netcf.vs2008_20090210.zip, Log4NetTest_20090210.zip, Modified_Files_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
[jira] Updated: (LOG4NET-164) using a named mutex for file appenders
[ https://issues.apache.org/jira/browse/LOG4NET-164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ron Grabowski updated LOG4NET-164: -- Attachment: MutexProcessLock.patch Added ProcessLock inner class alongside ExclusiveLock and MinimalLock that uses a Mutex to allows multiple processes to correctly lock to the same file without having to open and close the file for each write. ProcessLock name may need to change...MutexLock, InterProcessLock? 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-195) Log4Net Performance comparison with other logging utility
[ https://issues.apache.org/jira/browse/LOG4NET-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671480#action_12671480 ] Ron Grabowski commented on LOG4NET-195: --- You shouldn't have to build your own array...let log4net buffer the events and flush them when appropriate. Use a BufferingForwardingAppender that forwards to an async appender (this one queues items in the ThreadPool): http://svn.apache.org/viewvc/logging/log4net/trunk/examples/net/1.0/Appenders/SampleAppendersApp/cs/src/Appender/AsyncAppender.cs?view=markup If you're writing to a Sql Server database this is a helpful async appender: https://rhino-tools.svn.sourceforge.net/svnroot/rhino-tools/trunk/rhino-commons/Rhino.Commons/Logging/AsyncBulkInsertAppender.cs Here's another example: https://issues.apache.org/jira/browse/LOG4NET-190 Log4Net Performance comparison with other logging utility - Key: LOG4NET-195 URL: https://issues.apache.org/jira/browse/LOG4NET-195 Project: Log4net Issue Type: Test Affects Versions: 1.2.10 Environment: .Net Framework 2.0, VS 2005, Windows XP Reporter: Ashish Khandelwal Priority: Critical Attachments: Log4Net_Vs_nSpring.zip I developed one utility to compare the performance between Log4Net and nSpring(another logging utility). The result I saw is surprise to me - Log4Net took more time than nSpring. It is surprise because Log4net claims to be fast and flexible: speed first, flexibility second. Log4Net says: (http://logging.apache.org/log4net/release/manual/internals.html) One of the often-cited arguments against logging is its computational cost. This is a legitimate concern as even moderately sized applications can generate thousands of log requests. Much effort was spent measuring and tweaking logging performance. Log4net claims to be fast and flexible: speed first, flexibility second. Although test is saying Log4Net takes more time, I am still not convinced with the result achieved, considering the fact; Log4Net is widely accepted by the industry and known for its speed, reliability and flexibility. I would like to know why Log4Net is taking more time, we might be missing any setting or other which can boost the performance. Can you please help to know the reason? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-198) Memory leak on a very basic code
[
https://issues.apache.org/jira/browse/LOG4NET-198?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671515#action_12671515
]
Ron Grabowski commented on LOG4NET-198:
---
When I run the code below without starting logTimer Environment.WorkingSet
stays the same. When I run the code as shown the WorkingSet slowly increases:
namespace ConsoleApplication1
{
class Program
{
private static readonly ILog log =
LogManager.GetLogger(typeof(Program));
static void Main(string[] args)
{
XmlConfigurator.Configure();
var logTimer = new Timer(1000);
logTimer.Elapsed += delegate { log.Debug(Hello World); };
logTimer.Start();
var workingSetTimer = new Timer(500);
workingSetTimer.Elapsed += delegate {
Console.WriteLine(Environment.WorkingSet); };
workingSetTimer.Start();
Console.ReadLine();
}
}
}
When I use the BasicConfigurator with this appender:
class NullAppender : IAppender
{
public void Close()
{
// empty
}
public void DoAppend(LoggingEvent loggingEvent)
{
// empty
}
public string Name
{
get { return NullAppender; }
set { /* empty */ }
}
}
The WorkingSet value remains the same. That leads me to believe that if there
is any kind of leak its not in the core log4net code. I also ran this to see if
there is a natural increase in memory usage when you're writing to the file
system using a typical FileStream due to the Framework's internal buffering:
var fs = File.OpenWrite(log.txt);
var sw = new StreamWriter(fs);
var logTimer = new Timer(1000);
logTimer.Elapsed += delegate { sw.Write(Hello World); };
logTimer.Start();
There wasn't an increase in the WorkingSet.
That's my 15min short dive into the problem. I'm not sure WorkingSet is the
best measure for this type of stuff. I ran that code through ANTS Memory
Profiler but nothing jumped out at me. I don't think GC.Collect() is the
correct fix. If there's a problem it'll most likely be at the appender level.
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
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12671114#action_12671114 ] Ron Grabowski commented on LOG4NET-197: --- I tried it just now and was able to download ok. This issue comes up every now and then. I think one of the Apache mirrors has a bad file? 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-195) Log4Net Performance comparison with other logging utility
[
https://issues.apache.org/jira/browse/LOG4NET-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670533#action_12670533
]
Ron Grabowski commented on LOG4NET-195:
---
Wow, that's some interesting code. Let me see if I can summarize what you did:
You used this pattern string for log4net: %-5p %d %5rms %-22.22c{1} %-18.18M -
%m%n. You used this pattern for nspring: {date} {time} [{ln:uc}] {category}
{msg}\n. It looks like the log4net pattern string is doing quite a lot more in
terms of formatting don't you think?
You used a new StringBuilder to build the log4net message each time in the
tight loop but you used just one string StringBuilder in the nspring example.
Would you agree that its quite a bit more expense to make a new StringBuilder
each time within a loop rather than building the StringBuilder just once?
It appears that nspring uses background threads to write message to the file.
Log4net does the writing on the same thread by default. I suspect the large
time differences you're seeing is due to the fact that nspring is returning
after it has started the log process...not after all the log entries have
actually been written to the file.
You're trying to compare two unrelated things.
Log4Net Performance comparison with other logging utility
-
Key: LOG4NET-195
URL: https://issues.apache.org/jira/browse/LOG4NET-195
Project: Log4net
Issue Type: Test
Affects Versions: 1.2.10
Environment: .Net Framework 2.0, VS 2005, Windows XP
Reporter: Ashish Khandelwal
Priority: Critical
Attachments: Log4Net_Vs_nSpring.zip
I developed one utility to compare the performance between Log4Net and
nSpring(another logging utility). The result I saw is surprise to me -
Log4Net took more time than nSpring. It is surprise because Log4net claims
to be fast and flexible: speed first, flexibility second.
Log4Net says:
(http://logging.apache.org/log4net/release/manual/internals.html)
One of the often-cited arguments against logging is its computational cost.
This is a legitimate concern as even moderately sized applications can
generate thousands of log requests. Much effort was spent measuring and
tweaking logging performance. Log4net claims to be fast and flexible: speed
first, flexibility second.
Although test is saying Log4Net takes more time, I am still not convinced
with the result achieved, considering the fact; Log4Net is widely accepted by
the industry and known for its speed, reliability and flexibility.
I would like to know why Log4Net is taking more time, we might be missing any
setting or other which can boost the performance. Can you please help to know
the reason?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (LOG4NET-195) Log4Net Performance comparison with other logging utility
Here's are some intentionally dubious micro-benchmarks showing how to get more
bang-for-the-buck out of DateTime.Now in a tight loop. The cached DateTime
implementations are about 40% faster than the typical DateTime.Now. Internally
log4net uses DateTime.Now when creating a new LoggingEvent. Perhaps it would
benefit some people to optimize the repeated calls to DateTime.Now if there are
a lot of log messages being generated in a short amount of time...maybe things
like NHibernate's DEBUG logging would benefit? I thought the
CachedSecondDateTime which caches the ticks for a full second would be even
faster but its on par with CachedTicksDateTime:
class Program
{
static void Main(string[] args)
{
runner(new FrameworkDateTime());
runner(new CachedTicksDateTime());
runner(new CachedSecondDateTime());
runner(new HardCodedDateTime(DateTime.Now));
Console.ReadLine();
}
private static void runner(IDateTime dateTime)
{
using (var ms = new MemoryStream())
using (var writer = new StreamWriter(ms))
{
Stopwatch stopwatch = Stopwatch.StartNew();
for (int i = 0; i 100; i++)
{
writer.Write(dateTime.Now.Ticks);
}
stopwatch.Stop();
Console.WriteLine(dateTime + : + stopwatch.ElapsedMilliseconds);
}
}
public interface IDateTime
{
DateTime Now { get; }
}
public sealed class FrameworkDateTime : IDateTime
{
public DateTime Now
{
get { return DateTime.Now; }
}
}
public sealed class CachedTicksDateTime : IDateTime
{
private DateTime cachedDateTime;
private long cachedTicks = 0;
public DateTime Now
{
get
{
long environmentTickCount = Environment.TickCount;
if (environmentTickCount != cachedTicks)
{
cachedTicks = environmentTickCount;
cachedDateTime = DateTime.Now;
}
return cachedDateTime;
}
}
}
public sealed class CachedSecondDateTime : IDateTime
{
private DateTime cachedDateTime;
private long cachedTicks = 0;
public DateTime Now
{
get
{
long environmentTickCount = Environment.TickCount;
if (environmentTickCount cachedTicks)
{
cachedTicks = environmentTickCount +
TimeSpan.TicksPerSecond;
cachedDateTime = DateTime.Now;
}
return cachedDateTime;
}
}
}
public sealed class HardCodedDateTime : IDateTime
{
private readonly DateTime cachedDateTime;
public HardCodedDateTime(DateTime cachedDateTime)
{
this.cachedDateTime = cachedDateTime;
}
public DateTime Now
{
get { return cachedDateTime; }
}
}
}
NLog uses this clever trick to optmize calls to DateTime.Now. I'm pretty sure
log4net uses a similiar trick with the %date formatter.
- Original Message
From: Ron Grabowski (JIRA) j...@apache.org
To: log4net-dev@logging.apache.org
Sent: Wednesday, February 4, 2009 5:39:59 PM
Subject: [jira] Commented: (LOG4NET-195) Log4Net Performance comparison with
other logging utility
[
https://issues.apache.org/jira/browse/LOG4NET-195?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12670533#action_12670533
]
Ron Grabowski commented on LOG4NET-195:
---
Wow, that's some interesting code. Let me see if I can summarize what you did:
You used this pattern string for log4net: %-5p %d %5rms %-22.22c{1} %-18.18M -
%m%n. You used this pattern for nspring: {date} {time} [{ln:uc}] {category}
{msg}\n. It looks like the log4net pattern string is doing quite a lot more in
terms of formatting don't you think?
You used a new StringBuilder to build the log4net message each time in the
tight loop but you used just one string StringBuilder in the nspring example.
Would you agree that its quite a bit more expense to make a new StringBuilder
each time within a loop rather than building the StringBuilder just once?
It appears that nspring uses background threads to write message to the file.
Log4net does the writing on the same thread by default. I suspect the large
time differences you're seeing is due to the fact that nspring is returning
after it has started the log process...not after all the log entries have
actually been written to the file.
You're trying to compare two unrelated things.
Log4Net Performance comparison with other logging utility
-
Key: LOG4NET-195
URL: https://issues.apache.org
[jira] Commented: (LOG4NET-192) Memory leaks with large multi-threaded application in log4net DLL 1.2.0.30714
[ https://issues.apache.org/jira/browse/LOG4NET-192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12663126#action_12663126 ] Ron Grabowski commented on LOG4NET-192: --- You going to have to give us a little more information. Have you considered upgrading to the latest version of log4net? I know that log4net doesn't release often by 1.2.0-beta8 was released in 2003. That would make it about 6 years old. Memory leaks with large multi-threaded application in log4net DLL 1.2.0.30714 - Key: LOG4NET-192 URL: https://issues.apache.org/jira/browse/LOG4NET-192 Project: Log4net Issue Type: Bug Environment: Windows 2003, .NET framework 1.1 Reporter: Vibha Kapur Priority: Critical We've coded log4net (1.2.0-beta8) into our application. With log4net enabled we see our virtual memory increasing and never decreasing, over a period of time and particularly with stress testing the server runs out of memory and everything grinds to a halt. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Logging to a Listbox control
You might be able to take some code from this example: http://mail-archives.apache.org/mod_mbox/logging-log4net-user/200804.mbox/%3c658979.41804...@web80002.mail.sp1.yahoo.com%3e - Original Message From: herman404 herman@wachovia.com To: log4net-dev@logging.apache.org Sent: Monday, December 15, 2008 1:12:32 PM Subject: Logging to a Listbox control Hi, I am trying to set up a Listbox control so I can output the contents of a log in real time to a Winforms GUI. I am trying to use the MemoryAppender and bind the Listbox.DataSource to the array returned by the MemoryAppender but all it does is output log4net.Core.LoggingEvent to the listbox and nothing else. What is the best way to approach this problem? Is it best to use another appender, or am I going about binding the datasource to the control all wrong? Thanks, -- View this message in context: http://www.nabble.com/Logging-to-a-Listbox-control-tp21018841p21018841.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
[jira] Commented: (LOG4NET-189) XmlConfigurator.Configure(Stream) needs a a Stream with pointer at beginning
[ https://issues.apache.org/jira/browse/LOG4NET-189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656714#action_12656714 ] Ron Grabowski commented on LOG4NET-189: --- I think the current behavior is good enough...log4net starts reading the stream based on the stream's current position. XmlConfigurator.Configure(Stream) needs a a Stream with pointer at beginning Key: LOG4NET-189 URL: https://issues.apache.org/jira/browse/LOG4NET-189 Project: Log4net Issue Type: Improvement Reporter: Maik Priority: Trivial Is it possible to set the stream for configuring log4net to the beginning of the stream by default? In my application I created my own MemoryStream with an XML-Configuration for log4net. Trying to call XmlConfigurator.Configure(myStream), I got an Exeption of the type System.Xml.XmlException: Missing Root-Element. Setting the StreamPointer to the beginning by calling myStream.Seek(0, SeekOrigin.Begin); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-187) Add a Trace level with isTraceEnabled.
[ https://issues.apache.org/jira/browse/LOG4NET-187?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656719#action_12656719 ] Ron Grabowski commented on LOG4NET-187: --- I wasn't planning on changing the ILog interface for the 1.2.11 release. Maybe in the next version? 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 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. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (LOG4NET-188) RollingFileAppender log.1, log.2 are not being rolled by Date
[ https://issues.apache.org/jira/browse/LOG4NET-188?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12656729#action_12656729 ] Ron Grabowski commented on LOG4NET-188: --- Does it work when you use a simple datePattern like: MM-dd-? The issue of log4net not preserving the file extension has been fixed in the SVN. RollingFileAppender log.1, log.2 are not being rolled by Date - Key: LOG4NET-188 URL: https://issues.apache.org/jira/browse/LOG4NET-188 Project: Log4net Issue Type: Bug Components: Appenders Environment: .NET 2005, Microsoft Windows Server 2003 Reporter: Gulden Yazgan Fix For: 1.2.10 I am using log4net.dll v1.2.0.30714. My RollingFileAppender rolls only the .log file every day but ignores the log.1, log.2 etc... This is only happening on my Web Service. My Windows Service project does not have this problem. It works fine with the same log4net.dll version. I credted the log4net.txt. I am attaching a section of it below: Note: By looking at the RollingFileAppeder.cs, If StaticLogFileName=true, it is from a different date period should not appear. Am I wrong on this? log4net: DOMConfigurator: Loading Appender [RollingLogFileAppender] type: [log4net.Appender.RollingFileAppender] log4net: DOMConfigurator: Setting Property [File] to String value [D:\Apps\Agents\GFS\Strategyware\EnterpriseMQServices\Logs\Activity.log] log4net: DOMConfigurator: Setting Property [AppendToFile] to Boolean value [True] log4net: DOMConfigurator: Setting Property [DatePattern] to String value [.MM-dd-.log] log4net: DOMConfigurator: Setting Property [RollingStyle] to RollingMode value [Composite] log4net: DOMConfigurator: Setting Property [MaxSizeRollBackups] to Int32 value [20] log4net: DOMConfigurator: Setting Property [MaximumFileSize] to String value [15MB] log4net: DOMConfigurator: Setting Property [StaticLogFileName] to Boolean value [True] log4net: DOMConfigurator: Setting Property [ConversionPattern] to String value [%d [%t] %-5p %c [%x] - %m%n] log4net: DOMConfigurator: Setting Property [Layout] to object [log4net.Layout.PatternLayout] log4net: RollingFileAppender: Type = [0], r0 = [.12-31-1969.log], r1 = [.12-31-1969.log] log4net: RollingFileAppender: Type = [1], r0 = [.12-31-1969.log], r1 = [.12-31-1969.log] log4net: RollingFileAppender: Type = [2], r0 = [.12-31-1969.log], r1 = [.01-01-1970.log] log4net: RollingFileAppender: Searching for existing files in [D:\Apps\Agents\GFS\Strategyware\EnterpriseMQServices\Logs] log4net: RollingFileAppender: Ignoring file [activity.log.1] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.2] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.3] because it is from a different date period log4net: RollingFileAppender: Ignoring file [activity.log.4] because it is from a different date period -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Create new log file each time application is started
You'd have to do something like include the process id (or other unique identifier) in the file name for each instance. - Original Message From: Rob1234 [EMAIL PROTECTED] To: log4net-dev@logging.apache.org Sent: Friday, November 28, 2008 8:54:40 AM Subject: Create new log file each time application is started Hi I have a problem with log4net. I have an application which uses a RollingFileAppender. The applcation can be started multiple times from the same location. I want there to be a seperate log file each time the application is started. e.g. 5 apps running = 5 log files. Is there any way to do this in log4net? -- View this message in context: http://www.nabble.com/Create-new-log-file-each-time-application-is-started-tp20734792p20734792.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
Re: configSections getting compiler message.
You're using a RollingFileAppender but you're telling the root logger to use a
ConsoleAppender. Change the code to this:
appender-ref ref=RollingFileAppender /
From: Henry Padilla [EMAIL PROTECTED]
To: log4net-dev@logging.apache.org
Sent: Friday, November 14, 2008 1:04:03 PM
Subject: configSections getting compiler message.
I'm trying to use this in VS2005 .NET v2.0. I need to set the config up in the
App.config but I'm getting messages:
Could not find schema information for the element 'log4net'.
Could not find schema information for the element 'appender'.
...and so forth. I'm using the configSections example from the site and I can't
find anything wrong:
configSections
section name=log4net
type=log4net.Config.Log4NetConfigurationSectionHandler, log4net /
/configSections
log4net
appender name=RollingFileAppender
type=log4net.Appender.RollingFileAppender
file value=log.txt /
appendToFile value=true /
rollingStyle value=Size /
maxSizeRollBackups value=10 /
maximumFileSize value=100KB /
staticLogFileName value=true /
layout type=log4net.Layout.PatternLayout
conversionPattern value=%date [%thread] %-5level %logger
[%property{NDC}] - %message%newline /
/layout
/appender
root
level value=INFO /
appender-ref ref=ConsoleAppender /
/root
/log4net
What am I doing wrong? Am I doing anything wrong or do I simply ignore the
messages?
Thanks for the help.
Tom P.
Windows Live Hotmail now works up to 70% faster. Sign up today.
Re: conversionPattern parameters
http://logging.apache.org/log4net/release/sdk/log4net.Layout.PatternLayout.html From: Henry Padilla [EMAIL PROTECTED] To: log4net-dev@logging.apache.org Sent: Friday, November 14, 2008 1:07:20 PM Subject: conversionPattern parameters Where can I find a list of conversionPattern parameters? I remember there being a parameter that would display the method you were in but I can't find it anywhere. Tom P. Get 5 GB of storage with Windows Live Hotmail. Sign up today.
[jira] Commented: (LOG4NET-180) SMTPAppender not sending all emails
[
https://issues.apache.org/jira/browse/LOG4NET-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12646740#action_12646740
]
Ron Grabowski commented on LOG4NET-180:
---
What happens when you add this to the appender:
bufferSize value=1 /
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
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=[EMAIL PROTECTED] /
from value=[EMAIL PROTECTED] /
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.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (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:comment-tabpanelfocusedCommentId=12646749#action_12646749 ] Ron Grabowski commented on LOG4NET-178: --- What appenders are you using? Maybe you have an exclusive lock on something that is still being kept after the restart. Have you tried using the AdoNetAppender and/or appending the processid to your filename so every restart gets its own file? 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 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. - You can reply to this email to add a comment to the issue online.
Re: log4net support for .NET framework 3.5
3.5 can run assemblies all the way back to 1.0. The most recent release run fine under .NET 3.5. - Original Message From: dipankaronline [EMAIL PROTECTED] To: log4net-dev@logging.apache.org Sent: Saturday, October 25, 2008 9:46:39 AM Subject: log4net support for .NET framework 3.5 I just want to know that which version of log4net support Microsoft .NET framework 3.5? Is there any such version exists at all till now? -- View this message in context: http://www.nabble.com/log4net-support-for-.NET-framework-3.5-tp20164275p20164275.html Sent from the Log4net - Dev mailing list archive at Nabble.com.
[jira] Commented: (LOG4NET-167) ArrayOutOfBounds Exception in MemoryAppender.getEvents()
[ https://issues.apache.org/jira/browse/LOG4NET-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12642586#action_12642586 ] Ron Grabowski commented on LOG4NET-167: --- How are you using the MemoryAppender Kenny? Is it from a single thread? ArrayOutOfBounds Exception in MemoryAppender.getEvents() Key: LOG4NET-167 URL: https://issues.apache.org/jira/browse/LOG4NET-167 Project: Log4net Issue Type: Bug Components: Appenders Affects Versions: 1.2.10 Environment: Windows Vista and XP. Reporter: Kenny Clement Assignee: Ron Grabowski Getting this every once in a while. No specific reproduction scenario. Destination array was not long enough. Check destIndex and length, and the array's lower bounds. at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable) at System.Collections.ArrayList.ToArray(Type type) at log4net.Appender.MemoryAppender.GetEvents() -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (LOG4NET-64) [PATCH] to RollingFileAppender.cs to add the ability to preserve the log file name extension when rolling the log file.
[ https://issues.apache.org/jira/browse/LOG4NET-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12638872#action_12638872 ] ron edited comment on LOG4NET-64 at 10/12/08 10:36 AM: - My uploaded patch also fixes the issue when the filename is absolute like c:\\log.txt. The first two patches would write to the file correctly but would incorrectly place the rolled files in the \bin directory of the running program. was (Author: ron): My uploaded patch also fixes fixes the issue when the filename is absolute like c:\\log.txt. The first two patches would write to the file correctly but would incorrectly place the rolled files in the \bin directory of the running program. [PATCH] to RollingFileAppender.cs to add the ability to preserve the log file name extension when rolling the log file. --- Key: LOG4NET-64 URL: https://issues.apache.org/jira/browse/LOG4NET-64 Project: Log4net Issue Type: New Feature Components: Appenders Affects Versions: 1.2.9 Reporter: Joshua Bassett Assignee: Ron Grabowski Attachments: LOG4NET-64.patch, LOG4NET-64.patch, patch.txt Normally, when the log file is rolled the file name extension is not preserved. For example, file.log is rolled to file.log.1 or file.log.-MM-dd. However, this may not be desired in all cases and it may be necessary to preserve the log file name extension when the log file is rolled. Most notably, this feature is useful for maintaining file associations under Windows so that all log files can be associated with a particaular text viewer. For example, file.log is rolled to file.1.log or file.-MM-dd.log. This patch adds an additional boolean property PreserveLogFileNameExtension to the RollingFileAppender class which is used to toggle this behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Appender to run at a Schedule Time
Use a Timer?
// untested
public class AutoFlushSmtpAppender : SmtpAppender
{
private System.Timers.Timer timer;
private int interval;
/// summary
/// Flush interval in milliseconds.
/// /summary
public int Interval
{
get { return interval; }
set { interval = value; }
}
public override void ActivateOptions()
{
base.ActivateOptions();
ErrorHandler = new StopTimerErrorHandler(this, ErrorHandler);
timer = new Timer(Interval);
timer.Elapsed += delegate { Flush(); };
timer.Start();
}
protected override void OnClose()
{
stopTimer();
base.OnClose();
}
private void stopTimer()
{
if (timer.Enabled)
{
timer.Enabled = false;
timer.Stop();
}
}
class StopTimerErrorHandler : IErrorHandler
{
private readonly AutoFlushSmtpAppender appender;
private readonly IErrorHandler wrapped;
public StopTimerErrorHandler(AutoFlushSmtpAppender appender,
IErrorHandler wrapped)
{
this.appender = appender;
this.wrapped = wrapped;
}
public void Error(string message, Exception e, ErrorCode errorCode)
{
appender.stopTimer();
wrapped.Error(message, e, errorCode);
}
public void Error(string message, Exception e)
{
appender.stopTimer();
wrapped.Error(message, e);
}
public void Error(string message)
{
appender.stopTimer();
wrapped.Error(message);
}
}
}
- Original Message
From: HemantJPatel [EMAIL PROTECTED]
To: log4net-dev@logging.apache.org
Sent: Tuesday, September 30, 2008 11:29:53 AM
Subject: Appender to run at a Schedule Time
Hi,
I need to run the smtp appender at a specified interval of time.
Any ideas how I can do this to that the appender will run at specific
intervals and send all the buffered messages.
Any pointers will be helpful.
Thanks in advance.
Thanks,
Hemant
--
View this message in context:
http://www.nabble.com/Appender-to-run-at-a-Schedule-Time-tp19744455p19744455.html
Sent from the Log4net - Dev mailing list archive at Nabble.com.
