Logging can be very helpful in analyzing the (faulty) behavior of a server application in response to client requests. HypertextLogger is a simple component that produces HTML in response to logging instructions. Its main purpose it to provide a better readable log file. By choosing you favorite CSS, you can highlight what is important and leave other information unfocused (timestamps).
HTML log file
Upon creation of the logger, it produces a new .html file to which logging events are written. Because most Browsers can deal with open-ended (i.e. not properly closed by tags) HTML files, a single page can be used to collect lots of events. And if you let e.g. Apache serve these log files, you can monitor server applications remotely.
Features of the HypertextLogger are:
- the log can be custom CSS styled (info,warn and error levels may have different emphasis)
- the log can have a custom pattern for each event (write your own formatBlock)
- you can use any HTML markup (e.q. links to other resources)
- by choosing a FileRollingPolicy you can control how many events are logged onto a single HTML file
- [update] can capture Transcript output and include it in the log
Using the logger
| logger |
logger := Philemon.HypertextLogger onFileNamed: 'myproject.log'.
logger debug: 'This is debugging info only shown if level == #debug'.
logger link: 'http://blog.doit.st' title: 'Smalltalk in the Cloud'.
Logger API
Some examples using the logging api. See class methods for tests.
logger blue: 'Text in Blue'.
logger escaped: '<escaped>'.
logger red:[ logger strong: 'Bummer' ]. "use blocks to combine the api"
logger logException: aSignal. "writes a stack"
logger enabled: true.
logger printTimestamp.
logger printCurrentProcess.
Customizing the logger
You can override the CSS styles and the format of each log entry.
logger css: aDictionary. "mapping between css-class and its definition"
logger formatBlock: [:logger :logLevel :content | logger print: content ]. "provide your own entry formatting"
Setup the FileRollingPolicy
Instead of producing one single big file, you can specify a policy to control log file creation.
logger daily. "every day create a new log (unless no events)"
logger maximumSize: 100000. "if size reaches limit then create a new log"
logger maximumEntries: 1000. "limit on the number of events"
logger refreshEvery: 10. "10 seconds auto refresh by the browser"
HypertextLogger is implemented in VisualWorks Smalltalk and is available from the Cincom Public Store under MIT License.
In the upcoming release 1.1 of the SelfDiagnose task library, a new task has been added called CheckEndecaService. Endeca is commercial software that provides excellent Search services to e.g. e-commerce web applications. This particular task checks the availability of that service and can perform a simple query. To implement this, the following snippet has been used:
HttpENEConnection connection = new HttpENEConnection();
connection.setHostname(host);
connection.setPort(port);
UrlENEQuery eneQuery = new UrlENEQuery("N=0", "UTF-8");
ENEQueryResults eneResults = connection.query(eneQuery);
Navigation navigation = eneResults.getNavigation();
long numERecs = navigation.getTotalNumERecs();
double time = eneResults.getTotalNetworkAndComputeTime();
Without a full understanding, you can see that this snippet is using classes which belong to the Endeca API package. SelfDiagnose is a open-source library and therefore can and will not have any dependencies on commerical software. So how can we still use this code without the compile time dependencies?. Of course, in order to execute this code, the runtime dependencies must be available. It does not make sense to use the CheckEndecaService if your application is not using it.
One way is to use some scripting language that dynamically binds the objects. But then the SelfDiagnose package will have a dependency to that scripting language. Therefore, I choose a more lightweight solution which is completely based on the standard Java Reflection API. To make the code a bit more fluent, I created the class Instance which hides all the exception handling stuff.
Instance connection = Instance.create("com.endeca.navigation.HttpENEConnection");
connection.invoke("setHostname", eneHost);
connection.invoke("setPort", enePort);
Instance eneQuery = Instance.create("com.endeca.navigation.UrlENEQuery",new Object[]{query,"UTF-8"});
Instance eneResults= connection.invoke("N=0",eneQuery);
Instance navigation = eneResults.invoke("getNavigation");
long numERecs = navigation.invoke("getTotalNumERecs").longValue();
double time = eneResults.invoke("getTotalNetworkAndComputeTime").doubleValue();
Although the compilation no longer depends on the client jar of Endeca, it still does depend on the API. Future changes in the API may invalidate this solution. Putting a version identification in the class name of task will accomodate this.
How can I provide programs with self diagnostic behavior? How can I implement this in a way that has low impact on the way I write programs (or Java classes to be more specific). If programs could run such a self diagnose then perhaps it takes less time to find the cause of an observed problem.
These thoughts are sprung when I found an error in an application that went into production just a few days earlier. The problem itself was easily fixed (just a typo in some properties file) but I was a bit surprised that obviously my tests did not cover this particular execution path. Sure, I should have written more tests to have a higher coverage (JCoverage can tell me what percentage), but what if I had programmed this behavior differently(how?) such that a self diagnose run would have detected it?
So I started coding some classes and apply them to this particular application just to find out what the benefits could be and what efforts are. See project SelfDiagnose for my progress on this.
Feedshot