No oil painting

Sunrise yesterday, the first day of summer time.

Perhaps the colours’re misleading — that camera has some vivid setting — but that is how it looked in real life.

Log pollution and log4net

LevelRangeFilter

Small tip for configuring filters — take care with acceptOnMatch, read the documentation for the exact behaviour.

For example, to get a LevelRangeFilter to pass the event on the subsequent filters, use the following:

<filter type="log4net.Filter.LevelRangeFilter">
    <acceptOnMatch value="false" />
    <levelMin value="DEBUG" />
    <levelMax value="FATAL" />
</filter>
<filter type="log4net.Filter.LoggerMatchFilter">
    <loggerToMatch value="xxx-yyy-zzz"/>
</filter>
<filter type="log4net.Filter.DenyAllFilter" />

The default value for acceptOnMatch is true, so had we left it out we would be logging everything between DEBUG and FATAL.

FilterSkeleton.Decide

This is the operation that determines whether the filter should deny, accept or pass on a log event:.

[LoggerMatchFilter.Decide] The rendered message is matched against the LoggerToMatch. If the LoggerToMatch equals the beginning of the incoming LoggerName (StartsWith) then a match will have occurred. If no match occurs this function will return Neutral allowing other filters to check the event. If a match occurs then the value of AcceptOnMatch is checked. If it is true then Accept is returned otherwise Deny is returned.

[LevelMatchFilter.Decide] If the Level of the event matches the level of the filter then the result of the function depends on the value of AcceptOnMatch. If it is true then the function will return Accept, it it is false then it will return Deny. If the Level does not match then the result will be Neutral.

The value of acceptOnMatch can be important if you don’t want your filter to exit early. In this example, we have to set it to false on our LevelRangeFilter for this reason. Perhaps we would be better to reorder them.

References

• Filter classes
• Configuring log4net via XML
• Tutorial

Top n javascript gotchas

Recently we have discovered one or two Javascript quirks.

New lines in variable assignment

Javascript treats new lines as the end of a statement in some cases. For example, declaring a string variable:

This one works:

var result = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. " +
    "Etiam at tortor ac sapien ultricies cursus. " +
    "Vivamus sed mi vitae urna auctor consectetur."

While this one will result in an error:

var result =
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit. " +
    "Etiam at tortor ac sapien ultricies cursus. " +
    "Vivamus sed mi vitae urna auctor consectetur."

Json object declarations, commas and browser support

We encountered a problem with Internet Explorer. Care needs to be taken when declaring objects using json. Internet Explorer baulks at extra commas, the following will fail due to the extra comma after the result.count declaration.

var result = {
    name: "A test",
    count:0, // [!] THIS COMMA IS NOT ALLOWED
}

Neither Chrome nor Firefox complained.

We tracked this down using grep, something like this will find occurences:

$ grep -Plir ',[\s]*\}' * --include=*.js

One side issue with that was when the sequence occurs on the same line as the NUL character identifying the end of file.

This one matches:

While this one does not:

References

• Json memo
  The application/json Media Type for JavaScript Object Notation (JSON). provides information for the Internet community. It does
  not specify an Internet standard of any kind. Distribution of this
  memo is unlimited.
• Json Lint
  An online validator for json.