camitz | 22 Apr 16:00 2014
Picon

[GitHub] log4net pull request: Support for types with non-parameter less co...

GitHub user camitz opened a pull request:

    https://github.com/apache/log4net/pull/10

    Support for types with non-parameter less constructors in XmlHierarchyConfigurator.cs

    The constructor parameters are taken from the corresponding values of
    the child nodes.

    You can add for instance

         <standardunit type="Amazon.CloudWatch.StandardUnit">
              <value value="Kilobytes"/>
         </standardunit>

    where StandardUnit has only one constructor that has a string parameter
    named "value".

    To see why this is beneficial, see my
[CloudWatchAppender](https://github.com/camitz/CloudWatchAppender/tree/StandardUnit-in-config)
where I recently added support for the third party type above in config only to run into this obstacle.

    The changes are actually quite few, affecting some 50 lines. I don't know how to make git ignore white space changes.

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/camitz/log4net trunk

Alternatively you can review and apply these changes as the patch at:

(Continue reading)

Dan Ingalla (JIRA | 21 Apr 07:40 2014
Picon

[jira] [Updated] (LOG4NET-433) ThreadContext property not written to log when running on mono


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

Dan Ingalla updated LOG4NET-433:
--------------------------------

    Description: 
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

I verified the property is getting set via direct console output.

E.g.
{code}
ThreadContext.Properties["requestId"] = "_system_process";
var id = ThreadContext.Properties["requestId"];
Console.WriteLine("Request ID from thread context: {0}", id);
// Outputs: Request ID from thread context: _system_process
{code}

Now on both MS .Net and Mono the console output verifies that the thread context value is being set, but only
while running under the MS CLR does the request Id value get written to any logs. In Mono, the output is null.

This sounds like a Mono issue, but I figured I would report it anyway.

  was:
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

(Continue reading)

Dan Ingalla (JIRA | 21 Apr 07:40 2014
Picon

[jira] [Updated] (LOG4NET-433) ThreadContext property not written to log when running on mono


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

Dan Ingalla updated LOG4NET-433:
--------------------------------

    Description: 
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

I verified the property is getting set via direct console output.

E.g.
{code}
ThreadContext.Properties["requestId"] = "_system_process";
var id = ThreadContext.Properties["requestId"];
Console.WriteLine("Request ID from thread context: {0}", id);
// Outputs: Request ID from thread context: _system_process
{code}

Now on both MS .Net and Mono the console output verifies that the thread context value is being set, but only
while running under the MS CLR does the request Id value get written to any logs. In Mono, the output is null.

{{monospaced}}
Process ID: _sysprocess_f77318a0
Verify ThreadContext requestId: _sysprocess_f77318a0
04/20/2014 23:34:11 [_sysprocess_f77318a0-1/INFO ] XmlConfiguration: Load configuration from path
{{monospaced}}

(Continue reading)

Dan Ingalla (JIRA | 21 Apr 07:38 2014
Picon

[jira] [Updated] (LOG4NET-433) ThreadContext property not written to log when running on mono


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

Dan Ingalla updated LOG4NET-433:
--------------------------------

    Description: 
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

I verified the property is getting set via direct console output.

E.g.
{code}
ThreadContext.Properties["requestId"] = (some short GUID-like Id);
var id = ThreadContext.Properties["requestId"];
Console.WriteLine("Request ID from thread context: {0}", id);
{code}

Now on both MS .Net and Mono the console output verifies that the thread context value is being set, but only
while running under the MS CLR does the request Id value get written to any logs. In Mono, the output is null.

This sounds like a Mono issue, but I figured I would report it anyway.

  was:
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

I verified the property is getting set via direct console output.
(Continue reading)

Dan Ingalla (JIRA | 21 Apr 07:36 2014
Picon

[jira] [Updated] (LOG4NET-433) ThreadContext property not written to log when running on mono


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

Dan Ingalla updated LOG4NET-433:
--------------------------------

    Description: 
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on the MS CLR.

I verified the property is getting set via direct console output.

E.g.
ThreadContext.Properties["requestId"] = (some short GUID-like Id);
var id = ThreadContext.Properties["requestId"];
Console.WriteLine("Request ID from thread context: {0}", id);

Now on both MS .Net and Mono the console output verifies that the thread context value is being set, but only
while running under the MS CLR does the request Id value get written to any logs. In Mono, the output is null.

This sounds like a Mono issue, but I figured I would report it anyway.

  was:
When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on Windows.

I verified the property is getting set via direct console output.

E.g.
(Continue reading)

Dan Ingalla (JIRA | 21 Apr 07:32 2014
Picon

[jira] [Created] (LOG4NET-433) ThreadContext property not written to log when running on mono

Dan Ingalla created LOG4NET-433:
-----------------------------------

             Summary: ThreadContext property not written to log when running on mono
                 Key: LOG4NET-433
                 URL: https://issues.apache.org/jira/browse/LOG4NET-433
             Project: Log4net
          Issue Type: Bug
          Components: Appenders
         Environment: log4net 2.0.3 (Nuget version)
.Net version 4.0
            Reporter: Dan Ingalla

When running the assembly under Mono, a thread context property displays as 'null' in the log entries. This
does not occur on when running on Windows.

I verified the property is getting set via direct console output.

E.g.
ThreadContext.Properties["requestId"] = (some short GUID-like Id);
var id = ThreadContext.Properties["requestId"];
Console.WriteLine("Request ID from thread context: {0}", id);

Now on both MS .Net and Mono the console output verifies that the thread context value is being set, but only
while running under the MS CLR does the request Id value get written to any logs. In Mono, the output is null.

This sounds like a Mono issue, but I figured I would report it anyway.

--
This message was sent by Atlassian JIRA
(Continue reading)

Will Snipes (JIRA | 18 Apr 20:15 2014
Picon

[jira] [Commented] (LOG4NET-432) LogicalThreadContext properties cannot resolve


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

Will Snipes commented on LOG4NET-432:
-------------------------------------

RE: Dominik's comment
Yes the log4net library is loaded because while referencing the same log4net version 1.2.13.0, I changed
the properties from using ThreadLocalContext to ThreadContext and the unit tests passed.  In fact this is
what I finally did to work around the issue.

> LogicalThreadContext properties cannot resolve
> ----------------------------------------------
>
>                 Key: LOG4NET-432
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-432
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>         Environment: Windows 7 C#.NET 4.0 Visual Studio 13.0 MSTest
>            Reporter: Will Snipes
>            Priority: Minor
>
> Unit tests run with MSTest in my project report the following error when using LogicalThreadContext
properites.  They were previously working in version 1.2.11.0 of log4net.
> Unit Test Adapter threw exception: 
> Type is not resolved for member 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.13.0,
(Continue reading)

Dominik Psenner (JIRA | 18 Apr 16:53 2014
Picon

[jira] [Commented] (LOG4NET-432) LogicalThreadContext properties cannot resolve


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

Dominik Psenner commented on LOG4NET-432:
-----------------------------------------

Are you sure the log4net library is loaded by your unit tests?

> LogicalThreadContext properties cannot resolve
> ----------------------------------------------
>
>                 Key: LOG4NET-432
>                 URL: https://issues.apache.org/jira/browse/LOG4NET-432
>             Project: Log4net
>          Issue Type: Bug
>          Components: Core
>    Affects Versions: 1.2.13
>         Environment: Windows 7 C#.NET 4.0 Visual Studio 13.0 MSTest
>            Reporter: Will Snipes
>            Priority: Minor
>
> Unit tests run with MSTest in my project report the following error when using LogicalThreadContext
properites.  They were previously working in version 1.2.11.0 of log4net.
> Unit Test Adapter threw exception: 
> Type is not resolved for member 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.13.0,
Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'..
> Switching to using properties in ThreadContext works as does downgrading to version 1.2.11.0.

(Continue reading)

Will Snipes (JIRA | 18 Apr 15:53 2014
Picon

[jira] [Created] (LOG4NET-432) LogicalThreadContext properties cannot resolve

Will Snipes created LOG4NET-432:
-----------------------------------

             Summary: LogicalThreadContext properties cannot resolve
                 Key: LOG4NET-432
                 URL: https://issues.apache.org/jira/browse/LOG4NET-432
             Project: Log4net
          Issue Type: Bug
          Components: Core
    Affects Versions: 1.2.13
         Environment: Windows 7 C#.NET 4.0 Visual Studio 13.0 MSTest
            Reporter: Will Snipes
            Priority: Minor

Unit tests run with MSTest in my project report the following error when using LogicalThreadContext
properites.  They were previously working in version 1.2.11.0 of log4net.
Unit Test Adapter threw exception: 
Type is not resolved for member 'log4net.Util.PropertiesDictionary,log4net, Version=1.2.13.0,
Culture=neutral, PublicKeyToken=669e0ddf0bb1aa2a'..

Switching to using properties in ThreadContext works as does downgrading to version 1.2.11.0.

--
This message was sent by Atlassian JIRA
(v6.2#6252)

Howe, Peter L | 17 Apr 18:28 2014

Unsubscribing from this list

I am a contract employee at this company and my contract is ending and I need to unsubscribe from this list.  I
cannot find anything on the Apache web site to do so.  

Someone please help.

Thanks,
Peter


The information contained in this message may be privileged, confidential and protected from
disclosure. If the reader of this message is not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, you are hereby notified that any
dissemination, distribution or copying of this communication is strictly prohibited. If you have
received this communication in error, please notify your representative immediately and delete this
message from your computer. Thank you.
Günter Bögel | 16 Apr 15:47 2014
Picon

RE: Flush on idle (BufferingForwardingAppender)

Hi,
 
would be nice if the BufferingForwardingAppender could be configured to flush during idle times. So how about adding:
 
        private int m_flushOnIdle;
        private DateTime m_lastAppendTime=DateTime.Now;
 
        virtual public int FlushOnIdle
        {
            get { return m_flushOnIdle; }
            set
            {
                m_flushOnIdle = value;
                if (m_flushOnIdle==0) return;
                new Thread(() =>
                {
                    while (m_flushOnIdle>0) {
                        Thread.Sleep(m_flushOnIdle/2);
                        if (DateTime.Now - m_lastAppendTime > new TimeSpan(0, 0, 0, 0, m_flushOnIdle))
                            Flush();
                    }
                }){IsBackground = true}.Start();
            }
        }
 
And:
 
    override protected void Append(LoggingEvent loggingEvent)
    {
        m_lastAppendTime = DateTime.Now;
        ........
 
Regards,
Günter
           

Gmane