log4net-dev@logging.apache.org Archives

[GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed

2009-12-05T00:33:06Z

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 general@gump.apache.org.

Project logging-log4net has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 6 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: 10 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 216 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/StackTraceDetailPatternConverter.cs(62,17):
error CS0117: `System.Array' does not contain a definition for `Resize'
      [csc] /usr/lib/mono/1.0/mscorlib.dll (Location of the symbol related to previous error)
      [csc] Compilation failed: 1 error(s), 0 warnings

BUILD FAILED - 0 non-fatal error(s), 2 warning(s)

/srv/gump/public/workspace/logging-log4net/log4net.build(769,14):
External Program Failed: /usr/lib/mono/1.0/mcs.exe (return code was 1)

Total time: 7.1 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 07000005122009, vmgump:vmgump-public:07000005122009
Gump E-mail Identifier (unique within run) #2.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

Re: [jira] Updated: (LOG4NET-64) [PATCH] to RollingFileAppender.cs to add the ability to preserve the log file name extension when rolling the log file.

2009-12-03T04:12:38Z

Thanks for the patch. I'll get it merged in!



----- Original Message ----
From: Eike-Peter Falk (JIRA) 
To: log4net-dev@logging.apache.org
Sent: Wed, December 2, 2009 7:50:21 AM
Subject: [jira] Updated: (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:all-tabpanel
]

Eike-Peter Falk updated LOG4NET-64:
-----------------------------------

    Attachment: log4net-64.patch

This patch should fix this issue.

> [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
>             Fix For: 1.2.11
>
>         Attachments: log4net-64.patch, 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.yyyy-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.yyyy-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.

[GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed

2009-12-03T00:30:23Z

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 general@gump.apache.org.

Project logging-log4net has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 3 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: 20 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 216 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/StackTraceDetailPatternConverter.cs(62,17):
error CS0117: `System.Array' does not contain a definition for `Resize'
      [csc] /usr/lib/mono/1.0/mscorlib.dll (Location of the symbol related to previous error)
      [csc] Compilation failed: 1 error(s), 0 warnings

BUILD FAILED - 0 non-fatal error(s), 2 warning(s)

/srv/gump/public/workspace/logging-log4net/log4net.build(769,14):
External Program Failed: /usr/lib/mono/1.0/mcs.exe (return code was 1)

Total time: 7.7 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 09000003122009, vmgump:vmgump-public:09000003122009
Gump E-mail Identifier (unique within run) #2.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

[jira] Updated: (LOG4NET-64) [PATCH] to RollingFileAppender.cs to add the ability to preserve the log file name extension when rolling the log file.

2009-12-02T12:50:21Z


     [ https://issues.apache.org/jira/browse/LOG4NET-64?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Eike-Peter Falk updated LOG4NET-64:
-----------------------------------

    Attachment: log4net-64.patch

This patch should fix this issue.

> [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
>             Fix For: 1.2.11
>
>         Attachments: log4net-64.patch, 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.yyyy-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.yyyy-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.

[jira] Commented: (LOG4NET-234) RollingFileAppender generates incorrect file name

2009-12-02T11:10:21Z


    [ https://issues.apache.org/jira/browse/LOG4NET-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12784766#action_12784766
] 

Alex Vilela commented on LOG4NET-234:
-------------------------------------

I experience the same behavior. I have an IIS web application and the log files become multiplied:

datalog.2009.11.04.log
datalog.2009.11.04.log.2009.11.04.log
datalog.2009.11.04.log.2009.11.04.log.2009.11.04.log

Unlikely LOG4NET-175 everything keeps working fine and never crashes. 
The file isn't really rolled out, I mean, one file is not a sequence of the previous one.

Some logs happen on the first file, some on the second, then on the third, than log4net uses
the first again and keep switching between the log files, therefore reading the logs is really
hard.
Please see attached log files.

This is my configuration for the appender:
    
        
        
        
        
        

        
            
        
    

I'm using log4net 1.2.10.0

> RollingFileAppender generates incorrect file name
> -------------------------------------------------
>
>                 Key: LOG4NET-234
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-234
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 1.2.10
>         Environment: Windows XP, Windows 2003
>            Reporter: Miroslav Vanicky
>         Attachments: logs.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I have Appender defined as follow...
> 
>      
>     
>      
>      
>      
>     
>     
>       
>     
>   
> This Appender should generate file names like "Log_2009-10-15.txt", mostly it works fine,
but in some unknown situations it generates file named "Log_2009-10-15.txt_2009-10-15.txt".
It seems to me that this happens when there were no log-files and the incorrectly named file
was the first log-file generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LOG4NET-234) RollingFileAppender generates incorrect file name

2009-12-02T11:10:21Z


     [ https://issues.apache.org/jira/browse/LOG4NET-234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Alex Vilela updated LOG4NET-234:
--------------------------------

    Attachment: logs.zip

The log files I mentioned on the previous post.

> RollingFileAppender generates incorrect file name
> -------------------------------------------------
>
>                 Key: LOG4NET-234
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-234
>             Project: Log4net
>          Issue Type: Bug
>          Components: Appenders
>    Affects Versions: 1.2.10
>         Environment: Windows XP, Windows 2003
>            Reporter: Miroslav Vanicky
>         Attachments: logs.zip
>
>   Original Estimate: 24h
>  Remaining Estimate: 24h
>
> I have Appender defined as follow...
> 
>      
>     
>      
>      
>      
>     
>     
>       
>     
>   
> This Appender should generate file names like "Log_2009-10-15.txt", mostly it works fine,
but in some unknown situations it generates file named "Log_2009-10-15.txt_2009-10-15.txt".
It seems to me that this happens when there were no log-files and the incorrectly named file
was the first log-file generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed

2009-12-01T16:33:38Z

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 general@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: 30 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 216 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/StackTraceDetailPatternConverter.cs(62,17):
error CS0117: `System.Array' does not contain a definition for `Resize'
      [csc] /usr/lib/mono/1.0/mscorlib.dll (Location of the symbol related to previous error)
      [csc] Compilation failed: 1 error(s), 0 warnings

BUILD FAILED - 0 non-fatal error(s), 2 warning(s)

/srv/gump/public/workspace/logging-log4net/log4net.build(769,14):
External Program Failed: /usr/lib/mono/1.0/mcs.exe (return code was 1)

Total time: 9.7 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 11001601122009, vmgump:vmgump-public:11001601122009
Gump E-mail Identifier (unique within run) #1.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

[GUMP@vmgump]: Project logging-log4net (in module logging-log4net) failed

2009-12-01T00:33:17Z

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 general@gump.apache.org.

Project logging-log4net has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 108 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: 9 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 216 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/StackTraceDetailPatternConverter.cs(62,17):
error CS0117: `System.Array' does not contain a definition for `Resize'
      [csc] /usr/lib/mono/1.0/mscorlib.dll (Location of the symbol related to previous error)
      [csc] Compilation failed: 1 error(s), 0 warnings

BUILD FAILED - 0 non-fatal error(s), 2 warning(s)

/srv/gump/public/workspace/logging-log4net/log4net.build(769,14):
External Program Failed: /usr/lib/mono/1.0/mcs.exe (return code was 1)

Total time: 5.7 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 09000001122009, vmgump:vmgump-public:09000001122009
Gump E-mail Identifier (unique within run) #2.

--
Apache Gump
http://gump.apache.org/ [Instance: vmgump]

[jira] Created: (LOG4NET-240) Backup of logs are not created when application is running and at the same time date changes.

2009-11-30T09:29:20Z

Backup of logs are not created when application is running and at the same time date changes.
---------------------------------------------------------------------------------------------

                 Key: LOG4NET-240
                 URL: https://issues.apache.org/jira/browse/LOG4NET-240
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 1.2.10
         Environment: XP
            Reporter: renuka
            Priority: Critical


Hi,

I have set configuration properties as below.


			
			
			
			
			
			
			
			
				
			
		
When is in running mode, data gets locked correctely but in the mean time if date changes,
previous date's backup is not getting created. This happens only if application is running
else it works perfectely.

Please help.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LOG4NET-239) LoggingEvent m_cacheUpdatable is useless and even produce an unexpected behavior

2009-11-27T21:33:20Z

LoggingEvent m_cacheUpdatable is useless and even produce an unexpected behavior
--------------------------------------------------------------------------------

                 Key: LOG4NET-239
                 URL: https://issues.apache.org/jira/browse/LOG4NET-239
             Project: Log4net
          Issue Type: Bug
    Affects Versions: 1.2.10
         Environment: .Net 2.0
            Reporter: François Dumont


I already notify my problem on the mailing but as I had no answer I finally prefered to report
it here. Rather than copy/paste my mail I prefered to write a test that has to be added to
the BufferingAppenderTest:

        [Test, Description("Check that use of the BufferingAppender shall not change the rendering
of the log event.")]
        public void TestAppenderSkeletonBehavior()
        {
            SetupRepository();

            ObserverAppender observer = new ObserverAppender();
            m_bufferingForwardingAppender.AddAppender(observer);

            ILogger logger = m_hierarchy.GetLogger("test");

            logger.Log(typeof(BufferingAppenderTest), Level.Warn, "Message", new Exception("Exception"));
            Assert.AreEqual(1, observer.EventsCount);
            LoggingEvent loggingEvent1 = observer.Dequeue();

            // Lets see what happen if we do not fix the exception part of the logging event
at the
            // buffering forwarding appender level and let underlying appenders deal with
it:
            m_bufferingForwardingAppender.Fix ^= FixFlags.Exception;

            logger.Log(typeof(BufferingAppenderTest), Level.Warn, "Message", new Exception("Exception"));
            Assert.AreEqual(1, observer.EventsCount);
            LoggingEvent loggingEvent2 = observer.Dequeue();

            // The two logging events shall be similar:
            Assert.AreEqual(loggingEvent1.Level, loggingEvent2.Level);
            Assert.AreEqual(loggingEvent1.Domain, loggingEvent2.Domain);

            // Lets check the appender skeleton behavior: it normally renders the exception
string info
            // if the layout do not do so invoking the GetExceptionString method.
            Assert.IsNotNull(loggingEvent1.GetExceptionString(),
                             "Missing exception information when buffering appender fix it
!");
            Assert.IsNotNull(loggingEvent2.GetExceptionString(),
                            "Missing exception information when buffering appender do not
fix it !");
        }

This test needs this following small appender implementation to work:

    internal sealed class ObserverAppender : AppenderSkeleton
    {
        private readonly Queue loggingEvents;

        public int EventsCount
        {
            get { return this.loggingEvents.Count; }
        }

        public ObserverAppender()
        {
            this.loggingEvents = new Queue();
        }

        protected override void Append(LoggingEvent loggingEvent)
        {
            this.loggingEvents.Enqueue(loggingEvent);
        }

        public LoggingEvent Dequeue()
        {
            return this.loggingEvents.Dequeue();
        }
    }


For info I try to comment m_cacheUpdatable = false and notice no regression when running tests.
I would really be interested in knowing what this flag is for ?

Thanks

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: log4net v1.2.10 System.ArgumentException: Destination array was not long enough.

2009-11-25T18:19:26Z

This may occur due to synchronization issues because MemoryAppender isn't
thread-safe.
To fix this, provide your own thread-safe version for MemoryAppender by
synchronizing read/write operations, for example, with "lock" keyword.

jean leroux wrote:
> 
> Unhandled exception in application: System.ArgumentException: Destination
> array was not long enough. Check destIndex and length, and the array's
> lower bounds.
> 

-- 
View this message in context: http://old.nabble.com/log4net-v1.2.10-System.ArgumentException%3A-Destination-array-was-not-long-enough.-tp14633240p26517802.html
Sent from the Log4net - Dev mailing list archive at Nabble.com.

[jira] Commented: (LOG4NET-232) Use ReaderWriterLockSlim instead of ReaderWriterLock.

2009-11-25T08:10:40Z


    [ https://issues.apache.org/jira/browse/LOG4NET-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12782338#action_12782338
] 

Piers Williams commented on LOG4NET-232:
----------------------------------------

This is a real pain for us, because we are attempting to use Chess (MS Research) to test for
multithreaded behavoral correctness, and due to the deprication of ReaderWriterLock, Chess
doesn't support it (and throws NotImplementedExceptions when it encounters it).

So we're having to come up with evil ways to strip out log4net from our code under test. Unfortunately
even when our log4net code path isn't exercised at runtime, static class ctors in log4net
give us grief. Much of this seems to come down to LoggerManager hooking ProcessExit / DomainUnload
in it's static class ctor (which is pure evil by the way - why can't you just wait until the
first repository is created?), and it's in there that a ReaderWriterLock is used when the
repositories are shut down. I'm currently trying to unwire them using reflection which is
just horrible.

Looks like just a few changes to log4net.Util.ReaderWriterLock are all that's needed...

> Use ReaderWriterLockSlim instead of ReaderWriterLock.
> -----------------------------------------------------
>
>                 Key: LOG4NET-232
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-232
>             Project: Log4net
>          Issue Type: Improvement
>    Affects Versions: 1.2.10
>         Environment: Any
>            Reporter: Aron Weiler
>            Priority: Minor
>
> ReaderWriterLock should be replaced with ReaderWriterLockSlim according to Microsoft
for performance and simplification reasons.
> MSDN: http://msdn.microsoft.com/en-us/library/system.threading.readerwriterlock.aspx
> The .NET Framework has two reader-writer locks, ReaderWriterLockSlim and ReaderWriterLock.
ReaderWriterLockSlim is recommended for all new development. ReaderWriterLockSlim is similar
to ReaderWriterLock, but it has simplified rules for recursion and for upgrading and downgrading
lock state. ReaderWriterLockSlim avoids many cases of potential deadlock. In addition, the
performance of ReaderWriterLockSlim is significantly better than ReaderWriterLock. 

-- 
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-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

2009-11-22T20:44:40Z


    [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212
] 

Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:43 PM:
----------------------------------------------------------------

I created patch from Joshua Masek changes against the current revision in source control.
Hope it moves this issue little bit forward.

Personally I'm still on the way to understand the code to be able implement ideas from Ron's
comment (05/Jun/09 10:28).

Also I'm very surprised how the unit tests are complicated. I'd like to write unit tests for
this change... but there are missing completely unit tests for anything concerning date/time
:-(

      was (Author: felzmann):
    I created patch from Joshua Masek changes against the current revision in source control.
Hope it moves this issue little bit forward.

Personally I'm still on the way to understand the code to be able implement ideas from Ron's
comment (05/Jun/09 10:28).

Also I'm very surprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
  
> 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: LOG4NET-27.patch, 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.

[jira] Issue Comment Edited: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

2009-11-22T20:42:42Z


    [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212
] 

Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:41 PM:
----------------------------------------------------------------

I created patch from Joshua Masek changes against the current revision in source control.
Hope it moves this issue little bit forward.

Personaly I'm still on the way to understand the code to be able implement ideas from Ron's
comment (05/Jun/09 10:28).

Also I'm very supprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(

      was (Author: felzmann):
    This is patch created from last attachment posted by Joshua Masek.
  
> 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: LOG4NET-27.patch, 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.

[jira] Issue Comment Edited: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

2009-11-22T20:42:42Z


    [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12781212#action_12781212
] 

Petr Felzmann edited comment on LOG4NET-27 at 11/22/09 8:42 PM:
----------------------------------------------------------------

I created patch from Joshua Masek changes against the current revision in source control.
Hope it moves this issue little bit forward.

Personally I'm still on the way to understand the code to be able implement ideas from Ron's
comment (05/Jun/09 10:28).

Also I'm very surprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(

      was (Author: felzmann):
    I created patch from Joshua Masek changes against the current revision in source control.
Hope it moves this issue little bit forward.

Personaly I'm still on the way to understand the code to be able implement ideas from Ron's
comment (05/Jun/09 10:28).

Also I'm very supprised how the unit tests are complicated.
I'd like to write unit tests for this change...
but there are missing completely unit tests for anything concerning date/time :-(
  
> 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: LOG4NET-27.patch, 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.

[jira] Updated: (LOG4NET-27) Rolling files on date/time boundaries doesn't support a maximum number of backup files.

2009-11-22T20:40:39Z


     [ https://issues.apache.org/jira/browse/LOG4NET-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Petr Felzmann updated LOG4NET-27:
---------------------------------

    Attachment: LOG4NET-27.patch

This is patch created from last attachment posted by Joshua Masek.

> 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: LOG4NET-27.patch, 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.

[jira] Commented: (LOG4NET-235) IP Address Pattern Converter

2009-11-17T03:21:39Z


    [ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778703#action_12778703
] 

Adam Davies commented on LOG4NET-235:
-------------------------------------

We could create a class to hold all of the properties in which we are interested.  Called
it HttpContextInfo for lack of a better name, the LoggingEvent could contain a property of
type HttpContextInfo.  We could combine all of the AspNet Patterns into one pattern and use
options to display properties.

Example
aspnet-cache could become aspnet{cache}

or

aspnet-cache{item} could become aspnet{cache[item]}

> 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-235) IP Address Pattern Converter

2009-11-17T00:43:39Z


    [ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=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] Resolved: (LOG4NET-225) Multithreading and Deadlocks

2009-11-17T00:31:39Z


     [ 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.

svn commit: r881070 - in /logging/log4net/trunk: src/log4net.vs2005.csproj src/log4net.vs2005.sln src/log4net.vs2008.csproj src/log4net.vs2008.sln tests/src/log4net.Tests.vs2005.csproj tests/src/log4net.Tests.vs2008.csproj

2009-11-17T00:21:24Z

Author: rgrabowski
Date: Tue Nov 17 00:21:23 2009
New Revision: 881070

URL: http://svn.apache.org/viewvc?rev=881070&view=rev
Log:
Upgraded project files from vs2005 to vs2008.

Added:
    logging/log4net/trunk/src/log4net.vs2008.csproj
      - copied, changed from r826579, logging/log4net/trunk/src/log4net.vs2005.csproj
    logging/log4net/trunk/src/log4net.vs2008.sln
      - copied, changed from r826579, logging/log4net/trunk/src/log4net.vs2005.sln
    logging/log4net/trunk/tests/src/log4net.Tests.vs2008.csproj
      - copied, changed from r826579, logging/log4net/trunk/tests/src/log4net.Tests.vs2005.csproj
Removed:
    logging/log4net/trunk/src/log4net.vs2005.csproj
    logging/log4net/trunk/src/log4net.vs2005.sln
    logging/log4net/trunk/tests/src/log4net.Tests.vs2005.csproj

Copied: logging/log4net/trunk/src/log4net.vs2008.csproj (from r826579, logging/log4net/trunk/src/log4net.vs2005.csproj)
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/log4net.vs2008.csproj?p2=logging/log4net/trunk/src/log4net.vs2008.csproj&p1=logging/log4net/trunk/src/log4net.vs2005.csproj&r1=826579&r2=881070&rev=881070&view=diff
==============================================================================
--- logging/log4net/trunk/src/log4net.vs2005.csproj (original)
+++ logging/log4net/trunk/src/log4net.vs2008.csproj Tue Nov 17 00:21:23 2009
@@ -1,7 +1,7 @@
-ï»¿
+ï»¿
   
     Local
-    8.0.50727
+    9.0.30729
     2.0
     {181FE707-E161-4722-9F38-6AAAB6FAA106}
     Debug
@@ -25,6 +25,7 @@
     
     
     
+    2.0
   
   
     ..\build\bin\net\2.0\debug\
@@ -420,6 +421,7 @@
     
       Code
     
+    
     
     
       Code

Copied: logging/log4net/trunk/src/log4net.vs2008.sln (from r826579, logging/log4net/trunk/src/log4net.vs2005.sln)
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/log4net.vs2008.sln?p2=logging/log4net/trunk/src/log4net.vs2008.sln&p1=logging/log4net/trunk/src/log4net.vs2005.sln&r1=826579&r2=881070&rev=881070&view=diff
==============================================================================
--- logging/log4net/trunk/src/log4net.vs2005.sln (original)
+++ logging/log4net/trunk/src/log4net.vs2008.sln Tue Nov 17 00:21:23 2009
@@ -1,8 +1,8 @@
-Microsoft Visual Studio Solution File, Format Version 9.00
-# Visual Studio 2005
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "log4net.vs2005", "log4net.vs2005.csproj",
"{181FE707-E161-4722-9F38-6AAAB6FAA106}"
+Microsoft Visual Studio Solution File, Format Version 10.00
+# Visual Studio 2008
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "log4net.vs2008", "log4net.vs2008.csproj",
"{181FE707-E161-4722-9F38-6AAAB6FAA106}"
 EndProject
-Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "log4net.Tests.vs2005", "..\tests\src\log4net.Tests.vs2005.csproj",
"{B0530F10-0238-49A9-93B0-8EF412E90BCF}"
+Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "log4net.Tests.vs2008", "..\tests\src\log4net.Tests.vs2008.csproj",
"{B0530F10-0238-49A9-93B0-8EF412E90BCF}"
 EndProject
 Global
 	GlobalSection(SolutionConfigurationPlatforms) = preSolution

Copied: logging/log4net/trunk/tests/src/log4net.Tests.vs2008.csproj (from r826579, logging/log4net/trunk/tests/src/log4net.Tests.vs2005.csproj)
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/tests/src/log4net.Tests.vs2008.csproj?p2=logging/log4net/trunk/tests/src/log4net.Tests.vs2008.csproj&p1=logging/log4net/trunk/tests/src/log4net.Tests.vs2005.csproj&r1=826579&r2=881070&rev=881070&view=diff
==============================================================================
--- logging/log4net/trunk/tests/src/log4net.Tests.vs2005.csproj (original)
+++ logging/log4net/trunk/tests/src/log4net.Tests.vs2008.csproj Tue Nov 17 00:21:23 2009
@@ -1,7 +1,7 @@
-ï»¿
+ï»¿
   
     Local
-    8.0.50727
+    9.0.30729
     2.0
     {B0530F10-0238-49A9-93B0-8EF412E90BCF}
     Debug
@@ -25,6 +25,8 @@
     
     
     
+    2.0
+    v3.5
   
   
     ..\bin\Debug\
@@ -67,14 +69,17 @@
     prompt
   
   
-    
+    
       False
-      ..\..\..\IBatisNet\External-Bin\Net\2.0\nunit.framework.dll
+      ..\..\..\ibatisnet-3\External-Bin\Net\2.0\nunit.framework.dll
     
     
       System
     
     
+    
+      3.5
+    
     
       System.Data
     
@@ -165,9 +170,9 @@
     
   
   
-    
+    
       {181FE707-E161-4722-9F38-6AAAB6FAA106}
-      log4net.vs2005
+      log4net.vs2008

svn commit: r881069 - in /logging/log4net/trunk: src/Layout/Pattern/StackTraceDetailPatternConverter.cs src/Layout/Pattern/StackTracePatternConverter.cs src/Layout/PatternLayout.cs tests/src/Layout/PatternLayoutTest.cs

2009-11-17T00:20:54Z

Author: rgrabowski
Date: Tue Nov 17 00:20:54 2009
New Revision: 881069

URL: http://svn.apache.org/viewvc?rev=881069&view=rev
Log:
Applied additional patches for LOG4NET-154 to improve functionality of StackTracePatternConverter.

Added:
    logging/log4net/trunk/src/Layout/Pattern/StackTraceDetailPatternConverter.cs
Modified:
    logging/log4net/trunk/src/Layout/Pattern/StackTracePatternConverter.cs
    logging/log4net/trunk/src/Layout/PatternLayout.cs
    logging/log4net/trunk/tests/src/Layout/PatternLayoutTest.cs

Added: logging/log4net/trunk/src/Layout/Pattern/StackTraceDetailPatternConverter.cs
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/Layout/Pattern/StackTraceDetailPatternConverter.cs?rev=881069&view=auto
==============================================================================
--- logging/log4net/trunk/src/Layout/Pattern/StackTraceDetailPatternConverter.cs (added)
+++ logging/log4net/trunk/src/Layout/Pattern/StackTraceDetailPatternConverter.cs Tue Nov 17
00:20:54 2009
@@ -0,0 +1,90 @@
+using System;
+using System.Text;
+
+using log4net.Util;
+using log4net.Core;
+
+namespace log4net.Layout.Pattern
+{
+    /// 
+    /// Write the caller stack frames to the output
+    /// 
+    /// 
+    /// 
+    /// Writes the  to the output writer, using
format:
+    /// type3.MethodCall3(type param,...) > type2.MethodCall2(type param,...) > type1.MethodCall1(type
param,...)
+    /// 
+    /// 
+    /// Adam Davies
+    internal class StackTraceDetailPatternConverter : StackTracePatternConverter
+    {
+        internal override string GetMethodInformation(System.Reflection.MethodBase method)
+        {
+            string returnValue="";
+
+            try
+            {
+                string param = "";
+                string[] names = GetMethodParameterNames(method);
+                StringBuilder sb = new StringBuilder();
+                if (names != null && names.GetUpperBound(0) > 0)
+                {
+                    for (int i = 0; i <= names.GetUpperBound(0); i++)
+                    {
+                        sb.AppendFormat("{0}, ", names[i]);
+                    }
+                }
+
+                if (sb.Length > 0)
+                {
+                    sb.Remove(sb.Length - 2, 2);
+                    param = sb.ToString();
+                }
+
+                returnValue=base.GetMethodInformation(method) + "(" + param + ")";
+            }
+            catch (Exception ex)
+            {
+                LogLog.Error(declaringType, "An exception ocurred while retreiving method
information.", ex);
+            }
+
+            return returnValue;
+        }
+
+        private string[] GetMethodParameterNames(System.Reflection.MethodBase methodBase)
+        {
+            string[] returnValue = null;
+            try
+            {
+                System.Reflection.ParameterInfo[] methodBaseGetParameters = methodBase.GetParameters();
+                
+                int methodBaseGetParametersCount = methodBaseGetParameters.GetUpperBound(0);
+                Array.Resize(ref returnValue, methodBaseGetParametersCount + 1);
+
+                for (int i = 0; i <= methodBaseGetParametersCount; i++)
+                {
+                    returnValue[i] = methodBaseGetParameters[i].ParameterType + " " + methodBaseGetParameters[i].Name;
+                }
+            }
+            catch (Exception ex)
+            {
+                LogLog.Error(declaringType, "An exception ocurred while retreiving method
parameters.", ex);
+            }
+
+            return returnValue;
+        }
+
+        #region Private Static Fields
+
+        /// 
+        /// The fully qualified type of the StackTraceDetailPatternConverter class.
+        /// 
+        /// 
+        /// Used by the internal logger to record the Type of the
+        /// log message.
+        /// 
+        private readonly static Type declaringType = typeof(StackTracePatternConverter);
+
+        #endregion Private Static Fields
+    }
+}

Modified: logging/log4net/trunk/src/Layout/Pattern/StackTracePatternConverter.cs
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/Layout/Pattern/StackTracePatternConverter.cs?rev=881069&r1=881068&r2=881069&view=diff
==============================================================================
--- logging/log4net/trunk/src/Layout/Pattern/StackTracePatternConverter.cs (original)
+++ logging/log4net/trunk/src/Layout/Pattern/StackTracePatternConverter.cs Tue Nov 17 00:20:54
2009
@@ -18,8 +18,6 @@
 #endregion
 
 using System;
-using System.Globalization;
-using System.Text;
 using System.IO;
 using System.Diagnostics;
 
@@ -38,7 +36,7 @@
 	/// 
 	/// 
 	/// Michael Cromwell
-	internal sealed class StackTracePatternConverter : PatternLayoutConverter, IOptionHandler
+	internal class StackTracePatternConverter : PatternLayoutConverter, IOptionHandler
 	{
 		private int m_stackFrameLevel = 1;
 		
@@ -114,14 +112,26 @@
 				}
 				
 				StackFrame stackFrame = stackframes[stackFrameIndex];
-				writer.Write("{0}.{1}", stackFrame.GetMethod().DeclaringType.Name, stackFrame.GetMethod().Name);
+                writer.Write("{0}.{1}", stackFrame.GetMethod().DeclaringType.Name, GetMethodInformation(stackFrame.GetMethod()));
 				if (stackFrameIndex > 0)
 				{
+                    // TODO: make this user settable?
 					writer.Write(" > ");
 				}
 				stackFrameIndex--;
 			}
 		}
+
+                /// 
+        /// Returns the Name of the method
+        /// 
+        /// 
+        /// This method was created, so this class could be used as a base
class for StackTraceDetailPatternConverter
+        /// string
+        internal virtual string GetMethodInformation(System.Reflection.MethodBase method)
+        {
+            return method.Name;
+        }
 		
 		#region Private Static Fields
 

Modified: logging/log4net/trunk/src/Layout/PatternLayout.cs
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/src/Layout/PatternLayout.cs?rev=881069&r1=881068&r2=881069&view=diff
==============================================================================
--- logging/log4net/trunk/src/Layout/PatternLayout.cs (original)
+++ logging/log4net/trunk/src/Layout/PatternLayout.cs Tue Nov 17 00:20:54 2009
@@ -861,7 +861,8 @@
 			s_globalRulesRegistry.Add("timestamp", typeof(RelativeTimePatternConverter));
 			
 			s_globalRulesRegistry.Add("stacktrace", typeof(StackTracePatternConverter));
-			
+            s_globalRulesRegistry.Add("stacktracedetail", typeof(StackTraceDetailPatternConverter));
+
 			s_globalRulesRegistry.Add("t", typeof(ThreadPatternConverter));
 			s_globalRulesRegistry.Add("thread", typeof(ThreadPatternConverter));
 

Modified: logging/log4net/trunk/tests/src/Layout/PatternLayoutTest.cs
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/tests/src/Layout/PatternLayoutTest.cs?rev=881069&r1=881068&r2=881069&view=diff
==============================================================================
--- logging/log4net/trunk/tests/src/Layout/PatternLayoutTest.cs (original)
+++ logging/log4net/trunk/tests/src/Layout/PatternLayoutTest.cs Tue Nov 17 00:20:54 2009
@@ -69,6 +69,22 @@
 			stringAppender.Reset();
 		}
 
+        [Test]
+        public void TestStackTracePattern()
+        {
+            StringAppender stringAppender = new StringAppender();
+            stringAppender.Layout = new PatternLayout("%stacktrace{2}");
+
+            ILoggerRepository rep = LogManager.CreateRepository(Guid.NewGuid().ToString());
+            BasicConfigurator.Configure(rep, stringAppender);
+
+            ILog log1 = LogManager.GetLogger(rep.Name, "TestStackTracePattern");
+
+            log1.Info("TestMessage");
+            Assert.AreEqual("RuntimeMethodHandle._InvokeMethodFast > PatternLayoutTest.TestStackTracePattern",
stringAppender.GetString(), "stack trace value set");
+            stringAppender.Reset();
+        }
+
 		[Test]
 		public void TestGlobalPropertiesPattern()
 		{

svn commit: r881044 - /logging/log4net/trunk/tests/src/Util/LogLogTest.cs

2009-11-16T23:20:55Z

Author: rgrabowski
Date: Mon Nov 16 23:20:55 2009
New Revision: 881044

URL: http://svn.apache.org/viewvc?rev=881044&view=rev
Log:
Called Trace.Flush() to fix failing unit test.

Modified:
    logging/log4net/trunk/tests/src/Util/LogLogTest.cs

Modified: logging/log4net/trunk/tests/src/Util/LogLogTest.cs
URL: http://svn.apache.org/viewvc/logging/log4net/trunk/tests/src/Util/LogLogTest.cs?rev=881044&r1=881043&r2=881044&view=diff
==============================================================================
--- logging/log4net/trunk/tests/src/Util/LogLogTest.cs (original)
+++ logging/log4net/trunk/tests/src/Util/LogLogTest.cs Mon Nov 16 23:20:55 2009
@@ -30,6 +30,7 @@
             Trace.Listeners.Add(listTraceListener);
             LogLog.Error(GetType(), "Hello");
             LogLog.Error(GetType(), "World");
+            Trace.Flush();
             Assert.AreEqual(2, listTraceListener.Count);
 
             LogLog.EmitInternalMessages = false;

[jira] Assigned: (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message

2009-11-16T22:13:39Z


     [ 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] Created: (LOG4NET-238) Release date for Log4net version 1.2.11...

2009-11-16T10:40:39Z

Release date for Log4net version 1.2.11...
------------------------------------------

Key: LOG4NET-238
URL: https://issues.apache.org/jira/browse/LOG4NET-238
Project: Log4net
Issue Type: Improvement
Reporter: Paul Freeman

Hiya,

I have not been able to find out when the expected release date is scheduled for and it would
be nice if this information was available... even if it was just to say that there are no
plans to release the next version in the next 6 months, etc. I have searched the web and
found a couple of people asking this question but with no replies. Hence, I thought this
would be the best place to find out this information... apologies if this question should
be posted elsewhere.

In my particular case I would like to preserve the log file extensions, which according to
the forum has been fixed in 1.2.11. I would like to get an idea of when this is likely to
be released... shortly, months, years, etc. I don't want to patch my current version as I
can live without it for the time being, but I need to find out when this is likely to be released...
so I can provide feedback to others on when this new version is available.

Apologies again if this question is misplaced, but I would be very grateful if someone could
just give me an idea of the release date... or if I am just not looking in the right place,
forward me to the relevant place.

Thanks very much in advance for your help!

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (LOG4NET-13) Allow SMTPAppender to have replaceable parameters in Subject

2009-11-15T16:50:39Z


    [ https://issues.apache.org/jira/browse/LOG4NET-13?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778124#action_12778124
] 

rams.rapo commented on LOG4NET-13:
----------------------------------

Hi,

I have a similar need in Java application. Can the fix be propagated to log4j implementation
for Java. 
I'm using log4j 1.2.15 and had no luck passing run time parameters in subject line set by
MDC.




> Allow SMTPAppender to have replaceable parameters in Subject
> ------------------------------------------------------------
>
>                 Key: LOG4NET-13
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-13
>             Project: Log4net
>          Issue Type: Improvement
>          Components: Appenders
>    Affects Versions: 1.2.9
>         Environment: From sourceforge - 749620 - Jeremy Wiebe - jeropa
>            Reporter: Nicko Cadell
>             Fix For: 1.2.10
>
>
> It would be helpful to be able to have parameters that
> are replaced on a per-log event basis on the Subject
> line for the SMTPAppender.
> Example:
> I have multiple web servers running a .NET web service
> and all use log4net. When an error occurs, they use the
> SMTPAppender to notify me. It would be very useful to
> include the host name of the sender in the subject line
> so that I could easily determine which web server had
> an error instead of having to look into the email.
> In thinking more about this it could either be the
> Subject line or the From line that has replacable
> parameters. Perhaps even make it so that these
> properties can use the  tag.
> Jeremy Wiebe - jeropa

-- 
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

2009-11-09T16:38:17Z

I can happily confirm that this version is working great:
It is both debuggable, and compatible with existing assemblies that
reference it.
Ron - thank you very very much!

Omer.

On Mon, Nov 9, 2009 at 1:09 AM, Ron Grabowski wrote:

> I've contacted Omer off list to have him verify the .pdb file. If its
> correct I'll publish it somewhere.
>
> ------------------------------
> *From:* Omer Mor 
> *To:* Log4NET Dev 
> *Sent:* Mon, October 19, 2009 1:09:24 AM
>
> *Subject:* Re: Debugging log4net source
>
> Thanks!
>
> On Mon, Oct 19, 2009 at 5:04 AM, Ron Grabowski wrote:
>
>> I emailed Nicko asking him what I need to do to get the .snk file onto my
>> system. It looks like the version in source control is encrypted.
>>
>> ------------------------------
>> *From:* Omer Mor 
>> *To:* Log4NET Dev 
>> *Sent:* Wed, October 7, 2009 9:01:18 AM
>>
>> *Subject:* Re: Debugging log4net source
>>
>> I'm trying again to get some help from the log4net developers community:
>> I really need to get a release build with pdb.
>> I explained blow exactly what needs to be changed in the nant script to
>> build it this way.
>> It should only take a couple of minutes to do this.
>> I would have done it myself if the assembly signing key would have been
>> public.
>> Maybe if no one is free to compile it, then I could join the log4net dev
>> team, and get permission to access the signing key?
>>
>> Thanks in advance,
>>   Omer Mor.
>>
>> On Wed, Aug 26, 2009 at 5:01 PM, Omer Mor  wrote:
>>
>>> Thanks.
>>> First - you should change the nant script:
>>> In the file \log4net.include line 171 should be changed from:
>>>         
>>> to:
>>>         
>>> then just run the build script (build.cmd) and the release folder (
>>> \bin\net\2.0\release\) should contain both the dll and pdb files.
>>>
>>> I suggest making the change in the nant script permanent as it does not
>>> affect performance and allows for debugging into log4net source.
>>>
>>> Thanks in advance,
>>>   Omer Mor.
>>>
>>> On Wed, Aug 26, 2009 at 5:41 AM, Ron Grabowski wrote:
>>>
>>>> Tell me the exact nant command line to run and I'll run it.
>>>>
>>>> ------------------------------
>>>> *From:* Omer Mor 
>>>> *To:* Log4NET Dev 
>>>> *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.mor@gmail.com)
>>>>
>>>> On Fri, Aug 7, 2009 at 12:44 PM, Omer Mor  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 wrote:
>>>>>
>>>>>> Have you tried specifying a custom error handler on the appender
to
>>>>>> track down when it enters a failed state?
>>>>>>
>>>>>> 
>>>>>>   ...
>>>>>>   
>>>>>> 
>>>>>>
>>>>>> You would write one that sends an email when the file can't be
>>>>>> created.
>>>>>>
>>>>>> ------------------------------
>>>>>> *From:* Omer Mor 
>>>>>> *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.mor@gmail.com .
>>>>>>
>>>>>> Thanks in advance,
>>>>>>   Omer Mor.
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

[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.

2009-11-09T07:35:32Z


    [ https://issues.apache.org/jira/browse/LOG4NET-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774883#action_12774883
] 

Hakan Lindestaf edited comment on LOG4NET-64 at 11/9/09 7:35 AM:
-----------------------------------------------------------------

I have a problem with this issue, some of the files are still named in the old format.
Here's what my directory output looks like:
 Volume in drive C has no label.
 Volume Serial Number is 7057-2FE1

 Directory of C:\inetpub\wwwroot\KickService\Logs

11/09/2009  08:32 AM              .
11/09/2009  08:32 AM              ..
11/09/2009  07:56 AM            12,822 Service.log
10/28/2009  11:27 PM           748,549 Service.log20091028
10/29/2009  10:30 PM           738,261 Service.log20091029
11/05/2009  10:42 PM           819,465 Service.log20091105
11/06/2009  11:20 PM           873,142 Service.log20091106
11/07/2009  02:42 PM           148,499 Service.log20091107
11/08/2009  09:06 PM            81,809 Service.log20091108
10/16/2009  10:51 PM           586,003 Service20091016.log
10/20/2009  10:51 PM           654,559 Service20091020.log
10/21/2009  10:46 PM           848,594 Service20091021.log
10/22/2009  10:57 PM         6,586,212 Service20091022.log
10/25/2009  11:51 PM           264,567 Service20091025.log
10/26/2009  11:54 PM           908,770 Service20091026.log
10/27/2009  11:53 PM           426,759 Service20091027.log
10/30/2009  11:54 PM           456,209 Service20091030.log
10/31/2009  11:54 PM            26,600 Service20091031.log
11/01/2009  11:54 PM           153,698 Service20091101.log
11/02/2009  11:48 PM         1,194,835 Service20091102.log
11/03/2009  11:59 PM         2,587,370 Service20091103.log
11/04/2009  11:56 PM           846,138 Service20091104.log
11/09/2009  08:32 AM                 0 x.x
              21 File(s)     18,962,861 bytes
               2 Dir(s)  32,061,755,392 bytes free


See how there is a mix of the output formats. I haven't had a chance to look thru the code
yet. I'm running log4net from svn trunk. Here's my config:
    
      
      
      
      
      
      
      
      
        
      
    


      was (Author: hakanl):
    I have an issue with this issue, some of the files are still named in the old format.
Here's what my directory output looks like:
 Volume in drive C has no label.
 Volume Serial Number is 7057-2FE1

 Directory of C:\inetpub\wwwroot\KickService\Logs

11/09/2009  08:32 AM              .
11/09/2009  08:32 AM              ..
11/09/2009  07:56 AM            12,822 Service.log
10/28/2009  11:27 PM           748,549 Service.log20091028
10/29/2009  10:30 PM           738,261 Service.log20091029
11/05/2009  10:42 PM           819,465 Service.log20091105
11/06/2009  11:20 PM           873,142 Service.log20091106
11/07/2009  02:42 PM           148,499 Service.log20091107
11/08/2009  09:06 PM            81,809 Service.log20091108
10/16/2009  10:51 PM           586,003 Service20091016.log
10/20/2009  10:51 PM           654,559 Service20091020.log
10/21/2009  10:46 PM           848,594 Service20091021.log
10/22/2009  10:57 PM         6,586,212 Service20091022.log
10/25/2009  11:51 PM           264,567 Service20091025.log
10/26/2009  11:54 PM           908,770 Service20091026.log
10/27/2009  11:53 PM           426,759 Service20091027.log
10/30/2009  11:54 PM           456,209 Service20091030.log
10/31/2009  11:54 PM            26,600 Service20091031.log
11/01/2009  11:54 PM           153,698 Service20091101.log
11/02/2009  11:48 PM         1,194,835 Service20091102.log
11/03/2009  11:59 PM         2,587,370 Service20091103.log
11/04/2009  11:56 PM           846,138 Service20091104.log
11/09/2009  08:32 AM                 0 x.x
              21 File(s)     18,962,861 bytes
               2 Dir(s)  32,061,755,392 bytes free


See how there is a mix of the output formats. I haven't had a chance to look thru the code
yet. I'm running log4net from svn trunk. Here's my config:
    
      
      
      
      
      
      
      
      
        
      
    

  
> [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
>             Fix For: 1.2.11
>
>         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.yyyy-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.yyyy-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.

[jira] Commented: (LOG4NET-64) [PATCH] to RollingFileAppender.cs to add the ability to preserve the log file name extension when rolling the log file.

2009-11-09T07:35:32Z


    [ https://issues.apache.org/jira/browse/LOG4NET-64?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774883#action_12774883
] 

Hakan Lindestaf commented on LOG4NET-64:
----------------------------------------

I have an issue with this issue, some of the files are still named in the old format.
Here's what my directory output looks like:
 Volume in drive C has no label.
 Volume Serial Number is 7057-2FE1

 Directory of C:\inetpub\wwwroot\KickService\Logs

11/09/2009  08:32 AM              .
11/09/2009  08:32 AM              ..
11/09/2009  07:56 AM            12,822 Service.log
10/28/2009  11:27 PM           748,549 Service.log20091028
10/29/2009  10:30 PM           738,261 Service.log20091029
11/05/2009  10:42 PM           819,465 Service.log20091105
11/06/2009  11:20 PM           873,142 Service.log20091106
11/07/2009  02:42 PM           148,499 Service.log20091107
11/08/2009  09:06 PM            81,809 Service.log20091108
10/16/2009  10:51 PM           586,003 Service20091016.log
10/20/2009  10:51 PM           654,559 Service20091020.log
10/21/2009  10:46 PM           848,594 Service20091021.log
10/22/2009  10:57 PM         6,586,212 Service20091022.log
10/25/2009  11:51 PM           264,567 Service20091025.log
10/26/2009  11:54 PM           908,770 Service20091026.log
10/27/2009  11:53 PM           426,759 Service20091027.log
10/30/2009  11:54 PM           456,209 Service20091030.log
10/31/2009  11:54 PM            26,600 Service20091031.log
11/01/2009  11:54 PM           153,698 Service20091101.log
11/02/2009  11:48 PM         1,194,835 Service20091102.log
11/03/2009  11:59 PM         2,587,370 Service20091103.log
11/04/2009  11:56 PM           846,138 Service20091104.log
11/09/2009  08:32 AM                 0 x.x
              21 File(s)     18,962,861 bytes
               2 Dir(s)  32,061,755,392 bytes free


See how there is a mix of the output formats. I haven't had a chance to look thru the code
yet. I'm running log4net from svn trunk. Here's my config:
    
      
      
      
      
      
      
      
      
        
      
    


> [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
>             Fix For: 1.2.11
>
>         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.yyyy-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.yyyy-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: Debugging log4net source

2009-11-08T23:09:36Z

I've contacted Omer off list to have him verify the .pdb file. If its correct I'll publish
it somewhere.




________________________________
From: Omer Mor 
To: Log4NET Dev 
Sent: Mon, October 19, 2009 1:09:24 AM
Subject: Re: Debugging log4net source


Thanks!


On Mon, Oct 19, 2009 at 5:04 AM, Ron Grabowski  wrote:

>
>I emailed Nicko asking him what I need to do to get the .snk file onto my system. It looks
like the version in source control is encrypted.
>
>
>
>
________________________________
 >From: Omer Mor 
>To: Log4NET Dev 
>Sent: Wed, October 7, 2009 9:01:18 AM
>
>Subject: Re: Debugging log4net source
>
>
>
>I'm trying again to get some help from the log4net developers community:
>I really need to get a release build with pdb.
>I explained blow exactly what needs to be changed in the nant script to build it this
way.
>It should only take a couple of minutes to do this.
>I would have done it myself if the assembly signing key would have been public.
>Maybe if no one is free to compile it, then I could join the log4net dev team, and get
permission to access the signing key?
>
>
>Thanks in advance,
>  Omer Mor.
>
>
>On Wed, Aug 26, 2009 at 5:01 PM, Omer Mor  wrote:
>
>Thanks.
>>First - you should change the nant script:
>>In the file \log4net.include line 171 should be changed from:
>>        
>>to:
>>        
>>>>then just run the build script (build.cmd) and the release folder (\bin\net\2.0\release\)
should contain both the dll and pdb files.
>>
>>
>>I suggest making the change in the nant script permanent as it does not affect performance
and allows for debugging into log4net source.
>>
>>
>>Thanks in advance,
>>  Omer Mor.
>>
>>
>>On Wed, Aug 26, 2009 at 5:41 AM, Ron Grabowski  wrote:
>>
>>Tell me the exact nant command line to run and I'll run it.
>>>
>>>>>>
>>>
>>>
>>>
>>>
>>>
________________________________
From: Omer Mor 
>>>To: Log4NET Dev 
>>>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.mor@gmail.com)
>>>
>>>
>>>On Fri, Aug 7, 2009 at 12:44 PM, Omer Mor  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 
wrote:
>>>>
>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>Have you tried specifying a custom error handler on the appender to track
down when it enters a failed state?
>>>>>
>>>>>
>>>>>  ...
>>>>>  
>>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>You would write one that sends an email when the file can't be created.
>>>>>
>>>>>
>>>>>
________________________________
 >>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>From: Omer Mor 
>>>>>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.mor@gmail.com .
>>>>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 
>>>>>Thanks in advance,
>>>>>  Omer Mor.
>>>>
>>>
>>
>

[jira] Updated: (LOG4NET-237) URL Referrer Pattern Converter

2009-11-08T21:43:32Z


     [ https://issues.apache.org/jira/browse/LOG4NET-237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Davies updated LOG4NET-237:
--------------------------------

    Attachment: log4net - Url Referrer Address.zip

Created AspNetUrlReferrerPatternConverter.

Usage: %aspnet-urlreferrer

> URL Referrer Pattern Converter
> ------------------------------
>
>                 Key: LOG4NET-237
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-237
>             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 - Url Referrer Address.zip
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Need a URL Referrer Pattern Converter to provide the referring page's URL for the current
request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LOG4NET-237) URL Referrer Pattern Converter

2009-11-08T21:39:32Z

URL Referrer Pattern Converter
------------------------------

                 Key: LOG4NET-237
                 URL: https://issues.apache.org/jira/browse/LOG4NET-237
             Project: Log4net
          Issue Type: New Feature
          Components: Other
    Affects Versions: 1.2.10
            Reporter: Adam Davies
            Priority: Trivial
             Fix For: 1.2.10


Need a URL Referrer Pattern Converter to provide the referring page's URL for the current
request.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (LOG4NET-236) Request URL PatternConverter

2009-11-08T20:47:32Z


     [ https://issues.apache.org/jira/browse/LOG4NET-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Davies updated LOG4NET-236:
--------------------------------

    Attachment: log4net - Url Address.zip

Created AspNetUrlPatternConverter.

usage: %aspnet-url

> Request URL PatternConverter
> ----------------------------
>
>                 Key: LOG4NET-236
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-236
>             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 - Url Address.zip
>
>   Original Estimate: 0h
>  Remaining Estimate: 0h
>
> Need an URL Pattern Converter to provide the current requested URL.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Created: (LOG4NET-236) Request URL PatternConverter

2009-11-08T20:45:32Z

Request URL PatternConverter
----------------------------

                 Key: LOG4NET-236
                 URL: https://issues.apache.org/jira/browse/LOG4NET-236
             Project: Log4net
          Issue Type: New Feature
          Components: Other
    Affects Versions: 1.2.10
            Reporter: Adam Davies
            Priority: Trivial
             Fix For: 1.2.10


Need an URL Pattern Converter to provide the current requested URL.

-- 
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

2009-11-08T03:50:32Z


    [ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774716#action_12774716
] 

Adam Davies commented on LOG4NET-235:
-------------------------------------

In order to use this pattern use %aspnet-ipaddress


Example:
  
    
      
    
  

> 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] Updated: (LOG4NET-235) IP Address Pattern Converter

2009-11-08T03:48:32Z


     [ https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Davies updated LOG4NET-235:
--------------------------------

    Attachment: log4net - IP Address.zip

> 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] Created: (LOG4NET-235) IP Address Pattern Converter

2009-11-08T03:46:32Z

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


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] Updated: (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message

2009-11-08T00:44:32Z


     [ https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Adam Davies updated LOG4NET-154:
--------------------------------

    Attachment: log4net - StackTrace and StackTraceDetail.zip

> 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
>             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] Commented: (LOG4NET-154) Add a StackTracePatternConverter to display method calls leading up to log message

2009-11-08T00:40:32Z


    [ https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774694#action_12774694
] 

Adam Davies commented on LOG4NET-154:
-------------------------------------

I have further extended the functionality of the StackTracePatternConverter to allow the selection
of min / max frames.

Given: %message%exception%stacktrace{MAX|MIN}

Explantion: {MAX|MIN}
      The MAX controls how deep to display the stacktrace.  MAX displays the first n of the
stacktrace from the top item 
          (stacktrace[0] to stacktrace[n])
          Any int >= 0 will only allow the first x 
      The MIN is optional.  MIN sets the number of stacktrace items to skip from stacktrace[0]
          If MIN is greater than the number of stacktrace items, then no stacktrace will be
displayed.

 Example: %stacktrace{3}, displays       stacktrace[2] > stacktrace[1] > stacktrace[0]
 Example: %stacktrace{5}, displays       stacktrace[4] > stacktrace[3] > stacktrace[2]
> stacktrace[1] > stacktrace[0]
 Example: %stacktrace{3|1}, displays       stacktrace[2] > stacktrace[1] 
 Example: %stacktrace{-1}, displays       stacktrace[n] > stacktrace[n-1] > ... >
stacktrace[1] > stacktrace[0]
 Example: %stacktrace{-1|3}, displays       stacktrace[n] > stacktrace[n-1] > ... >
stacktrace[4] > stacktrace[3]


In addition I have created a new pattern StackTraceDetailPatternConverter.  This pattern inherits
from StackTracePatternConverter, and provides parameter information for each method.

Given: %message%exception%stacktracedetail{MAX|MIN}

 Example: %stacktrace{3}, displays       stacktrace[2](type param, ...) > stacktrace[1](type
param, ...) > stacktrace[0](type param, ...)
 Example: %stacktrace{3|1}, displays       stacktrace[2](type param, ...) > stacktrace[1](type
param, ...)

> 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
>             Fix For: 1.2.11
>
>         Attachments: 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.

LoggingEvent Fix property

2009-11-06T22:13:09Z

Hello

In my company we are using an AsyncAppender for asynchronous logging that we have implemented
ourselves and we are quite happy with it. From the start we had prepared a FixFields property
on this appender so that user can decide which fields has to be fixed by the appender before
passing it to nested appenders. The default value for this property is Partial.

I recently try to use it so that most of the logging event formatting is done in the logging
thread rather than in the thread that generate the log event. So I change the FixFields value
to ThreadName and discovered that it has an impact on the job performed by nested appenders.
For instance when I log an exception through a ConsoleAppender nested in a AsyncAppender I
have normally the following result:

ERROR Exception raised
System.ApplicationException: FOO
� AsyncAppenderTest.Program.ThrowException() dans C:\Dev\AsyncAppenderTest\AsyncAppenderTest\Program.cs:ligne
69
� AsyncAppenderTest.Program.Main(String[] args) dans C:\Dev\AsyncAppenderTest\AsyncAppenderTest\Program.cs:ligne
40

Once I changed the FixFields to simply ThreadName I had:

ERROR Exception raised

As you can see the log of the exception has disappeared. This is so with or without the %exception
in the PatternLayout.

The problem is in the LoggingEvent class. It looks like you cannot partially fix a LoggingEvent.
Once you fix some fields using the Fix property m_cacheUpdatable is set to false and when
the LoggingEvent reference is pass to the ConsoleAppender which call GetExceptionString this
method return an empty string because m_cacheUpdatable is false. What is m_cacheUpdatable
for exactly ? It looks like the intention is to avoid the same field to be fixed several time
but as all fields default value in LoggingEventData is null and is not null anymore once fixed
it seems enough to avoid the multiple fixes situation. Couldn't be LoggingEvent.m_cacheUpdatable
simply removed ?

Thanks

[jira] Created: (LOG4NET-234) RollingFileAppender generates incorrect file name

2009-10-28T17:33:59Z

RollingFileAppender generates incorrect file name
-------------------------------------------------

                 Key: LOG4NET-234
                 URL: https://issues.apache.org/jira/browse/LOG4NET-234
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
    Affects Versions: 1.2.10
         Environment: Windows XP, Windows 2003
            Reporter: Miroslav Vanicky


I have Appender defined as follow...


     
    
     
     
     

    
    
      
    
  

This Appender should generate file names like "Log_2009-10-15.txt", mostly it works fine,
but in some unknown situations it generates file named "Log_2009-10-15.txt_2009-10-15.txt".
It seems to me that this happens when there were no log-files and the incorrectly named file
was the first log-file generated.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.