... until the collector arrives ...

This "blog" is really just a scratchpad of mine. There is not much of general interest here. Most of the content is scribbled down "live" as I discover things I want to remember. I rarely go back to correct mistakes in older entries. You have been warned :)



Don and I discovered a rather nasty bug in ASP.NET configuration.  If you define a security policy involving a UrlMembershipCondition with an invalid URL, the permission appears to be granted to everything (or a randomly selected collection of components)!!!  I wonder whether the problem applies to .NET generally...



There was much wringing of hands trying to get the wellview ASP.NET application working on Andromeda.  At first, it appeared that the app required more privilege than is granted by default by ASP.NET.  However, it turned out that the problem was that application debugging was turned on.  The default trust level did not permit this.  Turning off debugging in the application's web.config file solved the problem.  I had not noticed this behaviour while developing on Nemesis.  Apparently, the 'out-of-the-box' behaviour on that machine was to grant the required debugging permissions (full trust!) to applications.  There is no global web.config file and the usual .NET config tool did not show any relevant rules.  So... the question is why is full trust being granted on Nemesis?  Update: it is because of the file:


This file contains a lot of .NET settings.  ASP.NET is configured in the system.web section.

One handy-dandy trick to note: there is an 'application tracing' setting in the web.config file.  When it is turned on, you can view the trace log by hitting trace.axd on your application's URL.


Adobe SVG Plug-in

You can install the Adobe SVG Plug-in (v6.0) into Mozilla or Firefox by copying the files NPSVG6.DLL and NPSVG6.zip from Program Files\Common Files\Adobe\SVG Viewer 6.0\Plugins to the plugins directory of the browser.

NTLM Support for Servlets

jCIFS supports NTLM for Servlet containers!


I was using awstats to analyze IIS server logs.  It requires Perl.  At first I was using Perl installed under CygWin, but I found that it did not handle newlines properly.  So I switched to ActiveState.  That worked.  I found out that the default IIS log format is a bit damaged.  It is missing two key pieces of information that awstats needs:  date(!) and bytes transferred.  I wrote a Perl script that adds the correct date to the beginning of each log line (extracting it from comments in the log) and adds a zero as a dummy byte count:

my $date = "<unknown>";
foreach (<>)
    if (/^#Date: ([^ ]*)/) { $date = $1; print $_; }
    elsif (/^#/) { print $_; }
    else { chomp; print $date . " " . $_ . " 0\n"; }

This made it possible for awstats to perform its analysis.  awstats is a bit finicky about configuration.  In the wwwroot/cgi-bin of the distribution, I created a configuration file named (for example), awstats.nemesis.conf (where nemesis is the host name).  I changed:

  • LogFile to point to the log file to analyze
  • LogFormat to "date time c-ip cs-method cs-uri-stem sc-status %bytesd"
  • SiteDomain to nemesis.
  • DirData to ../data.
  • DirIcons to <distribution directory>/wwwroot/icon

Then, I created the statistics by running this command in the cgi-bin directory:

awstats.pl -config=nemesis -update

Finally, I created the web pages with the command:

    -config=nemesis ^

I had to copy the configuration file into ..\..\tools for this to work.  Also, the output directory had to exist.

All-in-all, I wasn't that impressed with the reports generated.



What I was trying to do was create a DOM object that contains all of the ASP request variables, and feed that into an XSL program that computes the page.  It was a bit tricky:

<%@ Language = "JScript" %>
var xslDoc = Server.createObject("Msxml2.FreeThreadedDOMDocument.3.0");

var xmlDoc = Server.CreateObject("Msxml2.DOMDocument.3.0");

var parametersDoc = Server.CreateObject("Msxml2.DOMDocument.3.0");
var parameters = parametersDoc.createElement("parameters");
for (var k = new Enumerator(Request.queryString); !k.atEnd(); k.moveNext()) {
    var key = k.item();
    for (var v = 1; v <= Request.queryString(key).count; ++v) {
        var p = parametersDoc.createElement(key);

var xslt = Server.createObject("Msxml2.XSLTemplate.3.0");
xslt.stylesheet = xslDoc;
var xslProc = xslt.createProcessor();
xslProc.input = xmlDoc;
xslProc.addParameter("parameters", parameters);
Response.contentType = "text/html";

The trickiness lies in the bolded code.  Note the use of an Enumerator object, that collections use one-based indices, and that collections are indexed using function-call notation instead of array-index notation.

The next step would be to persist state in a session variable, passing that state in as a document to the XSLt and storing back the updated state returned by the XSLt (hiding it, say, in the <HEAD> tag of the HTML).  Alternatively, there could be two XSLt programs involved:  one to compute the new state and one to render the output.


I was struggling with an ASP page, trying to get all of the request variables.  I was using JScript, of course, since I cannot stand to use VBScript.  As it turns out, one needs to take special measures when attempting to access collections in JScript.  The pattern looks like this:

for (var key = new Enumerator(Request.queryString); !key.atEnd(); key.moveNext()) {


Here is an ASP snippet that injects request parameters into XSLT to generate a web page:

<%@ Language = "JScript" %>
var myparam = String(Request.queryString("myparam"));

var xslDoc = Server.createObject("Msxml2.FreeThreadedDOMDocument.4.0");

var xmlDoc = Server.CreateObject("Msxml2.DOMDocument.4.0");

var xslt = Server.createObject("Msxml2.XSLTemplate.4.0");
xslt.stylesheet = xslDoc;
var xslProc = xslt.createProcessor();
xslProc.input = xmlDoc;
xslProc.addParameter("myparam", myparam);


The LongVarChar problem from yesterday was solved by switching from an ODBC driver to an OLEDB provider.


When interfacing the WellView calculation engine to ASP.NET, I had to use the interop bridge to ADO so that WellView could share the data connection.  When I do this, cannot retrieve "text" fields (e.g. LongVarChar).  As usual.  It seems very few components can access these fields.  A quick solution was not forthcoming.

I stumbled across a good newbie XQuery compiler message: "no context for path expression".  It might mean you forgot to prefix a variable with a dollar sign.


While writing an XQuery, I ran into a problem with Saxon 7.9.1.  The following query:

typeswitch ("x")
case $e as element() return $e
default $x return $x

caused this error:

java.lang.IllegalStateException: Variable $x has not been fixed up

I reported the error to the saxon-help@lists.sourceforge.net mailing list.

Blog Archive