Month: December 2005

Taking advantage of the slowdown of traffic on the day of New Years eve I just upgraded one of our production servers from Domino 5.0.13 to Domino 7.0. The only issue was that the installer complained about being unable to uninstall the Windows service althrough the service was uninstalled correctly. After restarting the installation it completed without any other issues.

First impressions? Everything seems to be running so I cross my fingers…

A new 0-day Windows exploit is out. The exploit takes advantage of a built-in feature of the Windows Metafile image format that allows code to be executed if the Windows Metafile fails to load. Since this is a core Windows issue you will not be safe just resorting to Firefox. Actually just surfing to a website embedding a crafted image could infect your computer.

The workaround for now is to unregister the offending DLL on your Windows system. For more information refer to the show notes for the Sucurity Now! podcast episode 20.

Supplemental Resources and Links for Episode #20

Does anyone have any experience writing a custom LSX? The LSX is going to wrap some third-party/legacy C/C++ code.

So far I dug out an article from The VIEW (May/June 1998: “The Why and How of Building LotusScript Extensions with the LSX Toolkit”) but it would be really nice with a comment from someone who actually did it.

Is it pretty straight forward?, is the LSX Wizard the way to go?, should I stay away from it?

Please let me know if you have any experience to share…

We’re about to upgrade our DB2 boxes from v.7.2 to v.8.2 so it’s time to understand the DB2 UDB JDBC Universal Driver…

While the described approach is valid there is a caveat if the script library defining the singleton is loaded from multiple sources at the same time. Because of this the described approach, all though nice, doesn’t really solve the real problem with creating singletons in LotusScript. It is my opinion impossible to create a real singleton in LotusScript without resorting to document based synchronization, if the same script library is loaded from multiple sources at the same time.

The problems stems from the fact that all scripts are running within their own little memory space making it impossible to share memory between different instances of the same script.

The reason I am quite sure of this is that I spent considerable amounts of time in vain a month or so ago trying to do this. I needed to write a simple transaction manager for NotesDocument objects so that documents that were reserved where automatically rolled back if the calling document wasn’t saved.

Due to application requirements the active form had to have an embedded view showing the documents that had been checked out and hence was under “transaction control”, but since the LotusScript code in the embedded view would have no way of knowing when the document containing the embedded view was saved, the script library with the transaction manager needed to be loaded (Use’ed) from both the form and the embedded view. Using a real singleton should solve this problem just fine, but due to the LotusScript memory model this approach created two “singletons” which kinds of defied the point.

A simple way to demonstrate this behaviour is to have the singleton compute to unique value (e.g. @Unique) in its constructor and have it output the unique value at each method invocation. This way you would see two different singletons performing operations.

The solution was to have the transaction manager synchronize its state with an user-specific profile document before and after each operation. The performance of this approach is quite okay.

So be aware of this kind of behavour when creating singletons that may be loaded from multiple scripts at the same time.

Logging is central to all applications to find out what’s going on and to help in development and debugging. The NotesLog class from LotusScript just doesn’t cut it in that regard which is why we should be happy for OpenLog. I find OpenLog to be a valuable additional to my LotusScript development tool arsenal.

Before we could start using it in production we had to make a few changes to the standard OpenLog application (thank God for OpenSource):

1. Default location of openlog.nsf to be the same directory as the current database
2. SEVERITY_DEBUG and filtering on severity level at runtime
3. Grouping of log documents
4. A small bug fix

Below I will discuss each of the changes made in its own section. I would really like some feedback on the changes so please let me know if you have any. Of cause the changes will also be sent to Julian so he can decide whether to incorporate them in the standard application template.

It’s so much more fun when we share… 🙂

Ad. 1: Default location of openlog.nsf…
We normally recommend our customers to organize the databases on their servers with one application per directory (e.g. one directory for helpdesk, one for sales force automation etc.) Because of this it really makes sense for us to have an Openlog database per application residing in the application directory and to have the default location of the openlog.nsf be the openlog.nsf in the current directory.

This means we can use the same “Openlog Functions” script library for all applications without having to modify the path to the log database (in the Initialize event). Instead of hardcoding the logDbName variable to “openlog.nsf” we compute the path based on the current database path.

'** this should be the name and path of the database that
'** you're logging everything to -- you need to explicitly name
'** it because it probably won't be the database that you're
'** running agents from
Dim session As New NotesSession
Dim sep As String
If Left(session.Platform, 7) = "Windows" Then
   sep = ||
Else
   sep = |/|
End If
logDbName = Strleftback(session.CurrentDatabase.FilePath, sep) + sep + "OpenLog.nsf"

Ad. 2: SEVERITY_DEBUG and filtering…
One of the things I really like about the log4j (and similar) frameworks is the concept of logging levels and the ability to filter on the logging levels at runtime. OpenLog has the concept of logging levels but not the filtering at runtime.

OpenLog currently has the following logging levels:

• SEVERITY_HIGH
• SEVERITY_MEDIUM
• SEVERITY_LOW

These logging levels are fine but I really miss a SEVERITY_DEBUG. SEVERITY_DEBUG should be used to output information usable in troubleshooting situations so you can have an added log output without having to insert “Print” or “Msgbox” statements in the code.

The filtering at runtime means that the logging framework will filter the log records actually being written to the openlog.nsf database at runtime. The idea is that you specify a severity with every log statement in the application code, and a filter logging level to the logging framework. Below the filter logging level is set in the “OpenlogFunctions” script library but it could as well be taken from a configuration document in the OpenLog database
as well. There are pros and cons with each solution.

The default filter logging level should be SEVERITY_LOW which would make the logging framework ignore log requests of a lower severity that is log requests of severity SEVERITY_DEBUG. Setting the filter logging level to SEVERITY_HIGH would make the logging framework only output logging requests with SEVERITY_HIGH.

To incorporate this kind of functionality I have made the following changes (additions in italic).

Declarations
'** common severity types
Const SEVERITY_DEBUG = "-1"
Const SEVERITY_LOW = "0"
Const SEVERITY_MEDIUM = "1"
Const SEVERITY_HIGH = "2"

'** current severity level we log - we will log everything which is at the
'** specified level and higher
Dim logSeverityLevel As String


Initialize
'initialize logging filter severity level to LOW
logSeverityLevel = SEVERITY_LOW

LogErrorEx-method
Function LogErrorEx (msg As String, severity As String, doc As NotesDocument) As String
   '** log an error with some descriptive information
   On Error Goto processError
   If Cint(severity) < Cint(logSeverityLevel) Then Exit Function
   ...
   ...
End Sub

LogEvent-method
Function LogEvent (msg As String, severity As String, doc As NotesDocument) As Integer
   '** log a general event
   On Error Goto processError
   If Cint(severity) < Cint(logSeverityLevel) Then Exit Function
   ...
   ...
End Sub

Ad. 3: Grouping of log documents</b
We have a lot of agents that run multiple times a day. With the default behaviour of OpenLog it can be very difficult to distinguish the log documents from one execution from the log documents from another since they are listed together only separated by the time. To alleviate this we have added the concept of log document grouping.

Option Public
Option Explicit
Use "OpenLogFunctions"

Sub Initialize
   Dim i As Integer
   Dim j As Integer

   Call EnterGroup("Main loop (" & Now & ")")
   Call LogEvent("Starting to run...", SEVERITY_LOW, Nothing)
   For i=0 To 2
      Call EnterGroup("Interation - group " & i)
      For j=0 To 2
         Call LogEvent("Logging event " & j, SEVERITY_DEBUG, Nothing)
      Next
      Call LeaveGroup()
   Next
   Call LogEvent("Done running...", SEVERITY_LOW, Nothing)
End Sub

Function LogErrorEx (msg As String, severity As String, doc As NotesDocument) As String
   ...
   ...

   With globalLogItem
      ...
      ...

      If (stackTrace.traceData = "") Then
         ...
      Else
         ...
      End If

      'if the method is called without an actual error having occured (e.g. a flaw in
      'necessary setup) Error will be empty. Test for this and set message
      'accordingly
      If .errMsg = "" Then
         .errMsg = .message
      End If
   End With

   ...
   ...

End Function