Feel free to reuse whatever you need from the log4net source as long as you
respect the ASF license.


2013/7/31 Farrington, Linda <[email protected]>

>  Dominik,****
>
> ** **
>
> I know.  I can’t either.  The only thing I could think of it that it is
> some 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 code to do it from scratch, but if something already exists then I’d
> rather leverage that.****
>
> ** **
>
> Thanks,****
>
> ** **
>
> Linda****
>
> ** **
>
> *From:* Dominik Psenner [mailto:[email protected]]
> *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 keys getter.****
>
> ** **
>
> 2013/7/31 Farrington, Linda <[email protected]>****
>
> Dominik,****
>
>  ****
>
> I don’t think you’ve seen the 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 it
> is declared as internal and so I cannot access it.****
>
>  ****
>
> Thanks for trying though****
>
>  ****
>
> *From:* Dominik Psenner [mailto:[email protected]]
> *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.ReadOnlyPropertiesDictionary.GetKeys.html
> ****
>
>  ****
>
> 2013/7/31 Farrington, Linda <[email protected]>****
>
> Dominik,****
>
>  ****
>
> Seems obvious, but in our case, it’s not.   I am working within some apps
> that already exist that are calling this logging and trying to make these
> changes 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
> method in the asynchronous appender.  I have only the threading context to
> work with.  I don’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 [mailto:[email protected]]
> *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
> determine which fields are being sent:
>
> string[] fields = Properties["fields"];
> foreach(string field in fields) {
>     string value = Properties[field];
> }
>
> Cheers
>
> On 07/31/2013 03:10 PM, Farrington, Linda wrote:****
>
> My data is coming to me in the ThreadingContext.Properties collection.
> There are about 10 elements in there.  I can’t seem to find a way to get
> the data out of this 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 pass in different data in the collection.****
>
>  ****
>
> *From:* [email protected] [mailto:[email protected] <[email protected]>] *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
> like this:****
>
>  ****
>
> // Implementation of IAppender.DoAppend****
>
> public void DoAppend(LoggingEvent loggingEvent) {****
>
>     loggingEvent.Properties["ThreadId"] =
> Thread.CurrentThread.ManagedThreadId.ToString();****
>
>     loggingEvent.Properties["MyUserId"] = ...****
>
>     loggingEvent.Properties["MySessionId"] = ...****
>
>     ...****
>
>     AddToQueue(loggingEvent);****
>
> }****
>
>  ****
>
>  ****
>
> On Tue, Jul 30, 2013 at 5:42 PM, Farrington, Linda <[email protected]>
> 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 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 ThreadingContext because it does not have a GetEnumerator on
> it. How are you able to get data out of the threadContext?****
>
>  ****
>
> *From:* [email protected] [mailto:[email protected]] *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
> loggingEvent.Properties in the main thread, just before I add the
> loggingEvent 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
> http://logging.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 <[email protected]> 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.netasync operations as 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 <[email protected]>
> wrote:****
>
> We are trying to log asynchronously using an asynchronousadonetappender
> inherited from adonetappender.   Logging standard properties seems 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 = as well to no avail).  My question is this:  If I cannot
> use the threadcontext when running asynchronously, how should I pass custom
> properties into 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  #
> ##########################################################****
>



-- 
Dominik Psenner
## OpenPGP Key Signature #################################
# Key ID: B469318C                                       #
# Fingerprint: 558641995F7EC2D251354C3A49C7E3D1B469318C  #
##########################################################

Reply via email to