Add logging

[GoogleCodeExporter]

Sometimes the only way to troubleshoot errors is to read logs of what
happened. This is especially true for code that runs unattended, for
example processing of inbound notifications. 

Requirements

1. Add a merchanism to log what the code does, what XML is received, what
XML is sent.
2. The presence of logging should not make it harder to get the code
running for a merchant who doesn't want logging.
3. Merchants should be able to turn on logging with as little effort as
possible. A recompilation should not be needed. It should preferably be a
config file setting.

Original issue reported on code.google.com by martin.o...@gmail.com on 9 Dec 2006 at 10:21

[GoogleCodeExporter]

Original comment by martin.o...@gmail.com on 9 Dec 2006 at 10:23

• Added labels: Priority-Low
• Removed labels: Priority-Medium

[GoogleCodeExporter]

When helping merchants troubleshoot their implementations, it is clear that most
don't log sent and received XML. Yet if that XML was logged, troubleshooting 
would be
significantly easier.

One more requirement for this logging: it should not add more dependencies to 
other
libraries. If it did, we would break the upgrade path for many merchants.

Original comment by martin.o...@gmail.com on 14 Apr 2007 at 9:57

• Added labels: Priority-Medium
• Removed labels: Priority-Low

[GoogleCodeExporter]

The code that I have written debugs all the incoming messages, but not the 
outgoing. 
I even go to the extent of logging the http headers, because I am supporting 
multiple merchants with the same callback url.

I can see the value of logging the messages.

The problem with logging when it comes to simultaneous requests is all the 
information related to that request may not be sequential in the log file.

A solution for this is to create a threaded logger. This logger would queue up 
all 
the data for the given thread (request or response) and then push all the data 
at 
one time to the log.

I don’t think we should use enterprise library due to the complexity, we 
should just 
extend the current logger or modify the current logger to provide additional 
options.

This doesn’t solve the problem of logging incoming message unless we either:
1.  Modify the Deserialize event and just assume this is incoming and log if 
needed.
2.  Create a method to allow people to pass the message to the log.

It would take a few hours to make these changes, and I may make them to support 
my 
needs over the next few weeks.

This would be a good v1.3 enhancement.

Original comment by joseph.f...@gmail.com on 14 Apr 2007 at 10:20

[GoogleCodeExporter]

Sounds good! I am not sure if we should include logging in the Deserialize() 
method
or not. It's a hard question and there are good arguments either way.

/Martin

Original comment by martin.o...@gmail.com on 14 Apr 2007 at 10:55

[GoogleCodeExporter]

The client code should manage its log file size and be able to round robin it. 
Having
one huge, growing log file is an issue in production environment where logging 
would
be the most helpful.

One question: If the on/off switch for logging sits in the web.config file, 
does that
mean all user sessions will be destroyed when the merchant turns logging on or 
off?

Original comment by martin.o...@gmail.com on 16 Apr 2007 at 8:36

[GoogleCodeExporter]

There are two more things to consider here: 

1. We don't want to reinvent the wheel, so we should use an existing logging 
framework.
2. However, this is a dependency, and users may be using another framework for 
logging. 

I think the best way to solve this paradox is to add logging code to the ASPX
samples, not in the part of the code that is used as a library.

Original comment by martin.o...@gmail.com on 17 Apr 2007 at 1:09

[GoogleCodeExporter]

If we were to add logging per say to the framework, we should use the Debug and 
Trace statements. This way, people can add listeners as needed or use an off 
the 
shelf framework. When you do a release build, the Debug's are compiled out so 
they 
have no impact.

It is not a lot of work to add the debug statements. My code uses Debug and I 
have 
two listeners set up to log the information to different files.

Original comment by joseph.f...@gmail.com on 17 Apr 2007 at 1:29

[GoogleCodeExporter]

Sounds good. I will read up on Debug and Trace... it's been a while since I 
used them :-)

To make things clear, let's provide examples in the sample ASPX file on how to 
log
incoming and outgoing XML, so merchants can see how to do it.

Original comment by martin.o...@gmail.com on 17 Apr 2007 at 5:02

[GoogleCodeExporter]

So are you saying we should provide samples in the aspx pages so merchants can 
see 
how to log the Xml messages?

Ok, we will do that. The Send will be a little more difficult unless we show 
the 
calling of the GetXml method.

Joe

Original comment by joseph.f...@gmail.com on 17 Apr 2007 at 10:52

[GoogleCodeExporter]

Yes, only include logging in the ASPX pages. In the case of the checkout page, 
we
will have to show how merchants can pull out the XML with
EncodeHelper.Utf8BytesToString(Request.GetXml()). I recently received a 
question from
a merchant about how to do that.

Original comment by martin.o...@gmail.com on 17 Apr 2007 at 11:48

[GoogleCodeExporter]

Original comment by mihai.io...@gmail.com on 28 Mar 2011 at 11:12

• Changed state: WontFix