log4net - 1.2.9 Beta release

Log4net development is showing signs of life! After a long period of silence the 1.2.9 Beta has been released. Some highlights of the list of new features:

• New logging contexts
• GlobalContext
• ThreadContext
• LogicalThreadContext
• LoggingEvent
• .NET string formatting syntax
• Customizable levels
• RollingFileAppender roll once
• SmtpAppender authentication
• ... and more

Instrumentation - Logging

I started of with log4j in my Java days, and was quick with adopting another fine .NET port: log4net.

But for work, we had to consider Microsofts Enterprise Instrumentation Framework (EIF). But a little more reading revealed that this package is getting replaced with the newly designed Enterprise Library. This framework not only contains Logging, but also a design pattern for Configuration, Data Access, Exception handling, Security, etc.

The Enterprise Library is all looking pretty o.k. but it seemed to be overly designed, over complicated and getting pretty slow. Also on migrating from one Microsoft packages to another: there is no migration path. And no support is mentioned for the future. Seems like this is going for a Corba-death: Beautifully designed, complicated to use, and slow.
For a comparison overview see Daniel Cazzulino's EIF vs log4net feature comparison char

I always like fast and simple. So that takes me back to log4net. The only concern I have with log4net is that the latest view builds on Sourceforge all refer to beta releases that seems to be quite dated. But till so far I never had any issues with this latest beta release.

Scott Colestock also has been writing how log4net can be integrated with Biztalk 2004. So what else are we waiting for. Let me put in my 2 cents for some documentation on the conversionPattern:

The conversionPattern format

The conversion pattern is closely related to the conversion pattern of the printf function in C. A conversion pattern is composed of literal text and format control expressions called conversion specifiers.

You are free to insert any literal text within the conversion pattern.

Each conversion specifier starts with a percent sign (%) and is followed by optional format modifiers and a conversion character. The conversion character specifies the type of data, e.g. category, priority, date, thread name. The format modifiers control such things as field width, padding, left and right justification. The following is a simple example.

<appender name="FileAppender" type="log4net.Appender.FileAppender">
    <file value="c:\\log\\My.log">
    <appendtofile value="true">
    <layout type="log4net.Layout.PatternLayout">
        <conversionpattern value="%-5p [%t]: %m%n"/>
    </layout>
    </appender>

Then the statements

private static readonly log4net.ILog log = log4net.LogManager.GetLogger(typeof(MyType));
log.Debug("Message 1");

would yield the output

DEBUG [MyType]: Message 1

Note that there is no explicit separator between text and conversion specifiers. The pattern parser knows when it has reached the end of a conversion specifier when it reads a conversion character. In the example above the conversion specifier %-5p means the priority of the logging event should be left justified to a width of five characters. The recognized conversion characters are

Conversion Character	Effect
c	Used to output the category of the logging event. The category conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets. If a precision specifier is given, then only the corresponding number of right most components of the category name will be printed. By default the category name is printed in full. For example, for the category name "a.b.c" the pattern %c{2} will output "b.c".
C	Used to output the fully qualified class name of the caller issuing the logging request. This conversion specifier can be optionally followed by precision specifier, that is a decimal constant in brackets. If a precision specifier is given, then only the corresponding number of right most components of the class name will be printed. By default the class name is output in fully qualified form. For example, for the class name "org.apache.xyz.SomeClass", the pattern %C{1} will output "SomeClass". WARNING Generating the caller class information is slow. Thus, it's use should be avoided unless execution speed is not an issue.
d	Used to output the date of the logging event. The date conversion specifier may be followed by a date format specifier enclosed between braces. For example, %d{HH:mm:ss,SSS} or %d{dd MMM yyyy HH:mm:ss,SSS}. If no date format specifier is given then ISO8601 format is assumed. The date format specifier admits the same syntax as the time pattern string of the SimpleDateFormat. Although part of the standard JDK, the performance of SimpleDateFormat is quite poor. For better results it is recommended to use the log4j date formatters. These can be specified using one of the strings "ABSOLUTE", "DATE" and "ISO8601" for specifying AbsoluteTimeDateFormat, DateTimeDateFormat and respectively ISO8601DateFormat. For example, %d{ISO8601} or %d{ABSOLUTE}. These dedicated date formatters perform significantly better than SimpleDateFormat.
F	Used to output the file name where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
l	Used to output location information of the caller which generated the logging event. The location information depends on the JVM implementation but usually consists of the fully qualified name of the calling method followed by the callers source the file name and line number between parentheses. The location information can be very useful. However, it's generation is extremely slow. It's use should be avoided unless execution speed is not an issue.
L	Used to output the line number from where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
m	Used to output the application supplied message associated with the logging event.
M	Used to output the method name where the logging request was issued. WARNING Generating caller location information is extremely slow. It's use should be avoided unless execution speed is not an issue.
n	Outputs the platform dependent line separator character or characters. This conversion character offers practically the same performance as using non-portable line separator strings such as "\n", or "\r\n". Thus, it is the preferred way of specifying a line separator.
p	Used to output the priority of the logging event.
r	Used to output the number of milliseconds elapsed since the start of the application until the creation of the logging event.
t	Used to output the name of the thread that generated the logging event.
x	Used to output the NDC (nested diagnostic context) associated with the thread that generated the logging event.
X	Used to output the MDC (mapped diagnostic context) associated with the thread that generated the logging event. The X conversion character must be followed by the key for the map placed between braces, as in %X{clientNumber} where clientNumber is the key. The value in the MDC corresponding to the key will be output.
%	The sequence %% outputs a single percent sign.

By default the relevant information is output as is. However, with the aid of format modifiers it is possible to change the minimum field width, the maximum field width and justification.

The optional format modifier is placed between the percent sign and the conversion character.

The first optional format modifier is the left justification flag which is just the minus (-) character. Then comes the optional minimum field width modifier. This is a decimal constant that represents the minimum number of characters to output. If the data item requires fewer characters, it is padded on either the left or the right until the minimum width is reached. The default is to pad on the left (right justify) but you can specify right padding with the left justification flag. The padding character is space. If the data item is larger than the minimum field width, the field is expanded to accommodate the data. The value is never truncated.

This behavior can be changed using the maximum field width modifier which is designated by a period followed by a decimal constant. If the data item is longer than the maximum field, then the extra characters are removed from the beginning of the data item and not from the end. For example, it the maximum field width is eight and the data item is ten characters long, then the first two characters of the data item are dropped. This behavior deviates from the printf function in C where truncation is done from the end.

Below are various format modifier examples for the category conversion specifier.

Format modifier	left justify	minimum width	maximum width	comment
%20c	false	20	none	Left pad with spaces if the category name is less than 20 characters long.
%-20c	true	20	none	Right pad with spaces if the category name is less than 20 characters long.
%.30c	NA	none	30	Truncate from the beginning if the category name is longer than 30 characters.
%20.30c	false	20	30	Left pad with spaces if the category name is shorter than 20 characters. However, if category name is longer than 30 characters, then truncate from the beginning.
%-20.30c	true	20	30	Right pad with spaces if the category name is shorter than 20 characters. However, if category name is longer than 30 characters, then truncate from the beginning.

Below are some examples of conversion patterns.

%r [%t] %-5p %c %x - %m\n

This is essentially the TTCC layout.

%-6r [%15.15t] %-5p %30.30c %x - %m\n

Similar to the TTCC layout except that the relative time is right padded if less than 6 digits, thread name is right padded if less than 15 characters and truncated if longer and the category name is left padded if shorter than 30 characters and truncated if longer.

References:

• Loren Halvorson's Blog: Microsoft Enterprise Library Logging Block compared to Log4net
• Daniel Cazzulino's Blog: EIF vs log4net feature comparison
  
• Scott Colestock Blog: Diagnostic Tracing with BizTalk 2004
  
• Log4j API: Pattern Layout
  

Book Offer: Microsoft BizTalk Server 2004 unleashed

The book (by Scott Woodgate, Stephen Mohr, Brian Loesgen ISBN 0-672-32598-5) seems to be getting into it's final stage. There was a page advertisement in the MSDN magazine of November 2004 (Vol 19 NO 11 Page 108) offering a 30% discount for ordering the book from SamsPublishing.com (plus free shipping).

On Sams website I could not find any link or discount coupon. I opened an issue with Customer Service and they are contacting the Sams Marketing to inquire how we can get the 30% discount.

Update (18 Oct 2004):

I received an email from the Sams Marketing with the following information: In order to get the 30% discount you have to use the coupon code BIZTALK (note it must be all caps!). You enter the coupon code on the 'Payment Method' page in the order process. A review of the discount will be shown on the 'Place Order' page. The offer is valid till the Dec 15.

In a couple of days Sams website will provide a direct link.

Biztalk Competition Winners

Scott Woodgate published the list of Biztalk Competition Winners. The vocabulary upgrader got mentioned at point F!

The Vocabulary Upgrader is also available at Acumen Business. Also available on this site is the automatic Business Rule Verification;
the Policy Verificator.

BizTalk Vocabulary Upgrader goes beta

The BizTalk Vocabulary Upgrader has gone into beta.
The Vocabulary Upgrader enables to replace multiple references to different versions of a vocabulary to a single vocabulary version.

Have a look at the documentation, screenshots, getting started guide.

The tool is submitted to the Microsoft BizTalk Developers competition.

Dilbert on Circular Reasoning

With BizTalk 2004 it is possible to end up in 'execution loops', often this is referred to as circular reasoning. I was looking for some examples. Dilbert had the following illustration. Although it doesn't beat the example in the previous post.

Bush on Circular Reasoning

In the New York times [published June 18,2004]:

The New York Times > Washington > Bush and Cheney Talk Strongly of Qaeda Links With Hussein: "Mr. Bush, responding to a reporter's question about the report after a White House cabinet meeting yesterday morning, said: 'The reason I keep insisting that there was a relationship between Iraq and Saddam and Al Qaeda' is 'because there was a relationship between Iraq and Al Qaeda.' "

A great example of circular reasoning!

Download details: BizTalk Server 2004 Product Documentation

There is a new updated product documentation for BizTalk Server 2004 (7/23/2004).
Download details: BizTalk Server 2004 Product Documentation. There is a lot of new material about the Rule Engine, Engine Control Functions, Rule Action Side Effects etc.

BizTalk Server 2004 FAQ

A great resource for all those BizTalk 2004 server questions you have not found an answer for yet:

BizTalk Server 2004 FAQ - netologi.se

Windows XP SP2 - BizTalk 2004

The Service Pack 2 release for Microsoft XP has a lot of improvements on security settings. As a side-effect the regular install of the BizTalk 2004 Developers edition will fail at the Single Sign-On service.
It is all well documented by Microsoft, and easy to google if you know that the SP2 is responsible for the install failure, but just in case you did not make the link, read the article

The install failure is:

An unexpected error occurred while configuring the Single Sign-On server.
The service cannot be started, either because it is disabled or because it has no enabled devices associated with it.

Microsoft support article 841893 explains in detail how to resolve the issue by:

• Using Gpedit.msc to enforce the authentication of client calls

or

• Using Registry Editor to enforce the authentication of client calls

Watch your type

A simple rule:

Conditions:

  Case:/Root/Income/BasicSalary 

    is less than or equal to 75.000

Actions:

  Case:/Root/IncomeStatus = approved

Would a basic salary of only 800 be approved? Or rephrasing: would the rule fire?
I expected it would. But the answer is "It depends". It depeneds on the type of BasicSalary! If the BasicSalary is of type System.String it will not!

CONDITION EVALUATION TEST (MATCH) 6/28/2004 12:29:10 PM

Rule Engine Instance Identifier: 29fea928-...

Ruleset Name: Simple

Test Expression: TypedXmlDocument: Case:/Root/Income.BasicSalary <= 75.000

Left Operand Value: 800

Right Operand Value: 75.000

Test Result: False

It seems that the rule engine allows string comparison. And in case of string comparison "800" would be larger than "75.000"! So watch your types! An interesting item to explain to the rule writer!

What about converting the BasicSalary to an Int32?
I tried to add a .NET class in the Business Rules Composer. Selected the mscorlib to add as an assembly and changed the condition to:

Conditions:

  Int32.Parse(Case:/Root/Income/BasicSalary) 

    is less than or equal to 75.000

Actions:

  Case:/Root/IncomeStatus = approved

Don't know how to handle exceptions here, but let's see what happens:
I reloaded the policy, and mysteriously the 75.000 value was changed to 75! But hey, they also changed the type from System.String to System.Double. Close, but no cigar.

Should I put in 75,000? No: that got interpreted as an error where a string can not be compared with an Int32. And the policy could not be saved.

Let's continue and remove any thousand separator:

Conditions:

  Int32.Parse(Case:/Root/Income/BasicSalary)

    is less than or equal to 75000

Actions:

  Case:/Root/IncomeStatus = approved

Reloading the policy and we notice that the 75000 literal has type System.Int32. So we got the right type in place now.

Enterering the next stage: Testing if the rule actual fires. We can not define an instance of System.Int32 because of a missing interface. We need a fact creator. Although the Int32.Parse function is just a static method, we still have to assert the fact in the rule engine. Testing without the fact creation results in no rule-firing.

Hang in there, we are getting close. We only have to create a helper class that implements the Microsoft.RuleEngine.IFactCreator (located in the Microsoft.RuleEngine.dll)

namespace MarcoSoft.Utils

{

  /// 


  /// Summary description for Converter

  /// 

  public class Converter: Microsoft.RuleEngine.IFactCreator {

    public Converter() {

    }



    public int stringToInt32(string value){

	return Int32.Parse(value);

    }



    #region IFactCreator Members

    public object[] CreateFacts(RuleSetInfo ruleSetInfo) {

      return new object[]{new Converter()};

    }



    public Type[] GetFactTypes(RuleSetInfo ruleSetInfo) {

      Type converterType = this.GetType();

      return new Type[]{converterType};

    }

    #endregion

  }	

}

This code has to be compiled with a strong name, and be placed in the Global Assembly Cache. On the Facts Explorer view of the MS Business Rule Composer we can add the created .NET assembly.
We update the condition with:

Conditions:

  Converter.stringToInt32(Case:/Root/Income/BasicSalary) 

    is less than or equal to 75000

...

And in the Test Dialog we add a Fact.Creator of the MarcoSoft.Utils.Converter
Running the code, and voila:

CONDITION EVALUATION TEST (MATCH) 6/28/2004 5:22:18 PM

Rule Engine Instance Identifier: 52c89cd5-...

Ruleset Name: Simple

Test Expression: MarcoSoft.Utils.Converter.stringToInt32 <= 75000

Left Operand Value: 800

Right Operand Value: 75000

Test Result: True

The result what I was expecting all along.