Return-Path: X-Original-To: apmail-logging-log4net-dev-archive@www.apache.org Delivered-To: apmail-logging-log4net-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id B686410BA2 for ; Wed, 31 Jul 2013 18:44:46 +0000 (UTC) Received: (qmail 75199 invoked by uid 500); 31 Jul 2013 18:44:46 -0000 Delivered-To: apmail-logging-log4net-dev-archive@logging.apache.org Received: (qmail 75168 invoked by uid 500); 31 Jul 2013 18:44:46 -0000 Mailing-List: contact log4net-dev-help@logging.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: "Log4NET Dev" List-Id: Delivered-To: mailing list log4net-dev@logging.apache.org Received: (qmail 75138 invoked by uid 99); 31 Jul 2013 18:44:46 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Jul 2013 18:44:46 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW X-Spam-Check-By: apache.org Received-SPF: unknown mxmx:mail.global.sprint.commx:ms39026814.msv1.invalid.outlook.commx:mailserver.aclara.cominclude:spf.dynect.netip4:207.54.154.140~all (athena.apache.org: encountered unrecognized mechanism during SPF processing of domain of lfarrington@aclara.com) Received: from [216.32.180.31] (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.31) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 31 Jul 2013 18:44:41 +0000 Received: from mail160-va3-R.bigfish.com (10.7.14.233) by VA3EHSOBE005.bigfish.com (10.7.40.25) with Microsoft SMTP Server id 14.1.225.22; Wed, 31 Jul 2013 18:44:20 +0000 Received: from mail160-va3 (localhost [127.0.0.1]) by mail160-va3-R.bigfish.com (Postfix) with ESMTP id 4E64D44007A for ; Wed, 31 Jul 2013 18:44:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:207.54.154.137;KIP:(null);UIP:(null);IPV:NLI;H:EXP-EXCH02.aclaratech.com;RD:none;EFVD:NLI X-SpamScore: -3 X-BigFish: VS-3(z569dh2b68kzbb2dI98dI9371Ic85fh1443I148cI4015Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz8275ch1d7338h1de098h17326ah18c673h1de096h1954cbh8275bh8275dh1de097hz2dh87h2a8h668h839hd25h1288h12a5h12bdh137ah13eah1441h14ddh1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah1b2fh1bceh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) X-FB-DOMAIN-IP-MATCH: fail Received: from mail160-va3 (localhost.localdomain [127.0.0.1]) by mail160-va3 (MessageSwitch) id 1375296256553043_10928; Wed, 31 Jul 2013 18:44:16 +0000 (UTC) Received: from VA3EHSMHS014.bigfish.com (unknown [10.7.14.237]) by mail160-va3.bigfish.com (Postfix) with ESMTP id 7FE3E3C004D for ; Wed, 31 Jul 2013 18:44:16 +0000 (UTC) Received: from EXP-EXCH02.aclaratech.com (207.54.154.137) by VA3EHSMHS014.bigfish.com (10.7.99.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 31 Jul 2013 18:44:16 +0000 Received: from EXP-EXCH01.aclaratech.com ([fe80::b4db:3f2f:35dd:8c6b]) by EXP-EXCH02.aclaratech.com ([::1]) with mapi id 14.01.0379.000; Wed, 31 Jul 2013 13:44:15 -0500 From: "Farrington, Linda" To: Log4NET Dev Subject: RE: asynchronous logging Thread-Topic: asynchronous logging Thread-Index: Ac6NOcHHEcIQuwbqRA6tcKqt8cNWrAAQyD4AAAQXGoAACBGHEAADwtYAAAyglDAACwqJAAAIoI6QAAD8hQAACmomEP//uGmAgABTjUA= Date: Wed, 31 Jul 2013 18:44:14 +0000 Message-ID: <9F7B6581CBDCB949AFE78AC3B58D0FC05912F2DD@exp-exch01.aclaratech.com> References: <9F7B6581CBDCB949AFE78AC3B58D0FC05912EE94@exp-exch01.aclaratech.com> <9F7B6581CBDCB949AFE78AC3B58D0FC05912F02B@exp-exch01.aclaratech.com> <9F7B6581CBDCB949AFE78AC3B58D0FC05912F09E@exp-exch01.aclaratech.com> <51F91020.8060100@gmail.com> <9F7B6581CBDCB949AFE78AC3B58D0FC05912F0F2@exp-exch01.aclaratech.com> <9F7B6581CBDCB949AFE78AC3B58D0FC05912F29C@exp-exch01.aclaratech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.229] Content-Type: multipart/alternative; boundary="_000_9F7B6581CBDCB949AFE78AC3B58D0FC05912F2DDexpexch01aclara_" MIME-Version: 1.0 X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% X-Virus-Checked: Checked by ClamAV on apache.org --_000_9F7B6581CBDCB949AFE78AC3B58D0FC05912F2DDexpexch01aclara_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dominik, I know. I can't either. The only thing I could think of it that it is som= e security hole. Will open up an issue. (Do you know if there is a method= I could use to read the configuration dynamically? I can just write the c= ode to do it from scratch, but if something already exists then I'd rather = leverage that. Thanks, Linda From: Dominik Psenner [mailto:dpsenner@gmail.com] Sent: Wednesday, July 31, 2013 2:42 PM To: Log4NET Dev Subject: Re: asynchronous logging I see your point. In ThreadContext there's no way to get to the keys, even = though internally a dictionary is used. Please open a JIRA issue on this. C= an't think about a reason why there shouldn't be a keys getter. 2013/7/31 Farrington, Linda > Dominik, I don't think you've seen the object that I'm talking about. There is no g= etkeys() method on the threadcontext. That's why I have the issue in the f= irst place. Looks like I'll need to read the configuration file to get the= property names. There is a getProperties method on the object, but it is = declared as internal and so I cannot access it. Thanks for trying though From: Dominik Psenner [mailto:dpsenner@gmail.com= ] Sent: Wednesday, July 31, 2013 2:00 PM To: Log4NET Dev Subject: Re: asynchronous logging Easy as that: http://logging.apache.org/log4net/release/sdk/log4net.Util.ReadOnlyProperti= esDictionary.GetKeys.html 2013/7/31 Farrington, Linda > Dominik, Seems obvious, but in our case, it's not. I am working within some apps t= hat already exist that are calling this logging and trying to make these ch= anges without disrupting them. The app calls the logging like so: Push properties onto the threadcontext (fill threadcontext.properties) Call Log.Debug to log the error. At this point, I am now in the append me= thod in the asynchronous appender. I have only the threading context to wo= rk with. I don't see an overload to pass additional properites. So I am n= ot sure how creating a separate properties dictionary would solve this. (I= am new to log4net, so it's possible I am missing the obvious) Thanks, Linda From: Dominik Psenner [mailto:dpsenner@gmail.com= ] Sent: Wednesday, July 31, 2013 9:25 AM To: Log4NET Dev Subject: Re: asynchronous logging I may be pointing out the obvious, but why don't you let both applications = write to the same key a collection which lets your third application determ= ine which fields are being sent: string[] fields =3D Properties["fields"]; foreach(string field in fields) { string value =3D Properties[field]; } Cheers On 07/31/2013 03:10 PM, Farrington, Linda wrote: My data is coming to me in the ThreadingContext.Properties collection. The= re are about 10 elements in there. I can't seem to find a way to get the d= ata out of this collection as there is no way to iterate it and I don't kno= w what the fields are named. (We have two different applications and they = pass in different data in the collection. From: chinhdo@gmail.com [mailto:chinhdo@gmail.com= ] On Behalf Of Chinh Do Sent: Tuesday, July 30, 2013 10:07 PM To: Log4NET Dev Subject: Re: asynchronous logging Yes I was referring to log4net.Core.LoggingEvent.Properties. In my case, I know exactly what I need so I just had a few lines of code li= ke this: // Implementation of IAppender.DoAppend public void DoAppend(LoggingEvent loggingEvent) { loggingEvent.Properties["ThreadId"] =3D Thread.CurrentThread.ManagedThr= eadId.ToString(); loggingEvent.Properties["MyUserId"] =3D ... loggingEvent.Properties["MySessionId"] =3D ... ... AddToQueue(loggingEvent); } On Tue, Jul 30, 2013 at 5:42 PM, Farrington, Linda > wrote: Chinh Do, Thanks for your suggestion. This sounds like it might work. I did not wri= te this component, we are using one that someone else wrote and posted on g= ithub. Are you talking about the Properties() that is on the LoggingEvent = object? If so, there is a point in the code where I see the correct data i= n ThreadingContext. I could get it out of there and put it into Properties= . However, I have not been able to find a way to iterate through the Threa= dingContext because it does not have a GetEnumerator on it. How are you abl= e to get data out of the threadContext? From: chinhdo@gmail.com [mailto:chinhdo@gmail.com= ] On Behalf Of Chinh Do Sent: Tuesday, July 30, 2013 4:28 PM To: Log4NET Dev Subject: Re: asynchronous logging What I did my my AsyncAppender was to write thread specific data into loggi= ngEvent.Properties in the main thread, just before I add the loggingEvent t= o a queue. Then you can use "%P{}" in your log4net config sec= tion to get them later in the other thread. My AsyncAppender was based on log4net AsyncAppender example (see http://log= ging.apache.org/log4net/release/example-apps.html). The log events sent to = AsyncAppender are forwarded asynchronously to a list of attached appenders. On Tue, Jul 30, 2013 at 2:31 PM, George Chung > wrote: If you authored your own AsynchronousAdoNetAppender that uses the new .NET = async/await constructs, you could use the TPL library to wrap the ado.net async operations as a Task. Then if you avoid calling ConfigureAwait(false), I'm pretty sure the comple= tion routine will complete on the original ASP.NET request = thread, in which case you'll have access to the original HttpContext that s= tarted the request. On Tue, Jul 30, 2013 at 8:31 AM, Farrington, Linda > wrote: We are trying to log asynchronously using an asynchronousadonetappender inh= erited from adonetappender. Logging standard properties seems to work fin= e, but custom properties do not. I understand that this is because the asy= nchronous appender is logging the messages on another thread and we're stor= ing the custom properties in the logicalthreadcontext (tried threadcontext = =3D as well to no avail). My question is this: If I cannot use the thread= context when running asynchronously, how should I pass custom properties in= to log4net. Has anyone else done this? Can anyone provide any suggestions= ? Thanks in advance, Linda -- http://www.chinhdo.com -- http://www.chinhdo.com -- Dominik Psenner ## OpenPGP Key Signature ################################# # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ########################################################## -- Dominik Psenner ## OpenPGP Key Signature ################################# # Key ID: B469318C # # Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C # ########################################################## --_000_9F7B6581CBDCB949AFE78AC3B58D0FC05912F2DDexpexch01aclara_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dominik,

 <= /p>

I know.  I can’= ;t either.  The only thing I could think of it that it is some securit= y hole.  Will open up an issue.  (Do you know if there is a metho= d I could use to read the configuration dynamically?  I can just write the code= to do it from scratch, but if something already exists then I’d rath= er leverage that.

 <= /p>

Thanks,=

 <= /p>

Linda

 <= /p>

From: Dominik = Psenner [mailto:dpsenner@gmail.com]
Sent: Wednesday, July 31, 2013 2:42 PM
To: Log4NET Dev
Subject: Re: asynchronous logging

 

I see your point. In ThreadContext there's no way to= get to the keys, even though internally a dictionary is used. Please open = a JIRA issue on this. Can't think about a reason why there shouldn't be a k= eys getter.

 

2013/7/31 Farrington, Linda <lfarrington@aclara.com>=

Dominik,

 

I don’t think you’ve seen t= he object that I’m talking about.  There is no getkeys() method = on the threadcontext.  That’s why I have the issue in the first place.=   Looks like I’ll need to read the configuration file to get the= property names.  There is a getProperties method on the object, but i= t is declared as internal and so I cannot access it.

 

Thanks for trying though

 

From: Dominik Psenner [mailt= o:dpsenner@gmail.co= m]
Sent: Wednesday, July 31, 2013 2:00 PM


To: Log4NET Dev
Subject: Re: asynchronous logging

 

 

2013/7/31 Farrington, Linda <lfarrington@aclara.com>

Dominik,

 

Seems obvious, but in our case, it̵= 7;s not.   I am working within some apps that already exist that are calling this logging and trying to make these changes without disrupti= ng them.    

 

The app calls the logging like so:

Push properties onto the threadcontext&= nbsp; (fill threadcontext.properties)

Call Log.Debug  to log the error.&= nbsp; At this point, I am now in the append method in the asynchronous appender.  I have only the threading context to work with.  I do= n’t see an overload to pass additional properites.  So I am not = sure how creating a separate properties dictionary would solve this.  = (I am new to log4net, so it’s possible I am missing the obvious)

 

Thanks,

 

Linda

 

From: Dominik Psenner [mailt= o:dpsenner@gmail.co= m]
Sent: Wednesday, July 31, 2013 9:25 AM


To: Log4NET Dev
Subject: Re: asynchronous logging

 

I may be pointing out the obvious, but why don't you let both appl= ications write to the same key a collection which lets your third applicati= on determine which fields are being sent:

string[] fields =3D Properties["fields"];
foreach(string field in fields) {
    string value =3D Properties[field];
}

Cheers

On 07/31/2013 03:10 PM, Farrington, Linda wrote:

My data is coming to me in the Threadin= gContext.Properties collection.  There are about 10 elements in there.  I can’t seem to find a way to get the data out of th= is collection as there is no way to iterate it and I don’t know what = the fields are named.  (We have two different applications and they pa= ss in different data in the collection.

 

From: chinhdo@gmail.com [mailto:chinhdo@gm= ail.com] On Behalf Of Chinh Do
Sent: Tuesday, July 30, 2013 10:07 PM
To: Log4NET Dev
Subject: Re: asynchronous logging

 

Yes I was referring to log4net.Core.LoggingEvent.Properties.<= /o:p>

 

In my case, I know exactly what I need so I just had a few lines o= f code like this:

 

// Implementation of IAppender.DoAppend

public void DoAppend(LoggingEvent loggingEvent) {

    loggingEvent.Properties["ThreadId"] =3D Thread.= CurrentThread.ManagedThreadId.ToString();

    loggingEvent.Properties["MyUserId"] =3D ...

    loggingEvent.Properties["MySessionId"] =3D ...<= /span>

    ...

    AddToQueue(loggingEvent);

}

 

 

On Tue, Jul 30, 2013 at 5:42 PM, Farrington, Linda <lfarrington@aclara.com= > wrote:

Chinh Do,

Thanks for your suggestion.  This = sounds like it might work.  I did not write this component, we are using one that someone else wrote and posted on github.  Are you = talking about the Properties() that is on the LoggingEvent object?  If= so, there is a point in the code where I see the correct data in Threading= Context.  I could get it out of there and put it into Properties.  However, I have not been able to find a way = to iterate through the ThreadingContext because it does not have a GetEnume= rator on it. How are you able to get data out of the threadContext?<= o:p>

 

From: chinhdo@gmail.com [mailto:chinhdo@gm= ail.com] On Behalf Of Chinh Do
Sent: Tuesday, July 30, 2013 4:28 PM
To: Log4NET Dev
Subject: Re: asynchronous logging

 

What I did my my AsyncAppender was to write thread specific data i= nto loggingEvent.Properties in the main thread, just before I add the loggi= ngEvent to a queue. Then you can use "%P{<PropertyName>}" in your log4net config section to get= them later in the other thread.

 

My AsyncAppender was based on log4net AsyncAppender example (see&n= bsp;http://logging.apache.org/log4net/release/example-apps.h= tml). The log events sent to AsyncAppender are forwarded asynchronously to a lis= t of attached appenders.

 

On Tue, Jul 30, 2013 at 2:31 PM, George Chung <george@glympse.com> wrote:

If you authored your own AsynchronousAdoNetAppender that uses the = new .NET async/await constructs, you could use the TPL library to wrap the ado.net async operations a= s a Task.

 

Then if you avoid calling ConfigureAwait(false), I'm pretty sure the completion = routine will complete on the original ASP.NET request thread, in= which case you'll have access to the original HttpContext that started the= request.

 

 

On Tue, Jul 30, 2013 at 8:31 AM, Farrington, Linda <lfarrington@aclara.com= > wrote:

We are trying to log asynchronously using an asynchronousadonetappender = inherited from adonetappender.   Logging standard properties seem= s to work fine, but custom properties do not.  I understand that this = is because the asynchronous appender is logging the messages on another thread and we're storing the custom properties in = the logicalthreadcontext (tried threadcontext =3D as well to no avail).&nbs= p; My question is this:  If I cannot use the threadcontext when runnin= g asynchronously, how should I pass custom properties into log4net.  Has anyone else done this?  Can anyone provide an= y suggestions?

 

Thanks in advance,

 

Linda

 

 

 

 



 

--
http://www.chinhdo.com=



 

--
http://www.chinhdo.com=

 



 

--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C                &= nbsp;                    =   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##########################################################



 

--
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C                &= nbsp;                    =   #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##########################################################

--_000_9F7B6581CBDCB949AFE78AC3B58D0FC05912F2DDexpexch01aclara_--