Today I opened a database where a developer insists on writing almost all code in SSJS. A bit odd because OpenNTF Domino API is enabled and used in this particular application. I guess JAVA is still frightening. But because of SSJS you get unexpected behaviour which are difficult to catch in OpenLog. Because this implementation requires a component ID, which is hard to get if your code resides in script libraries, I thought it is time to write a simple helper class in Java so at least “some” for of exceptions can be captured. But then I stumbled upon this post where is mentioned that there is a SSJS helper script library in TaskJam which allows you to log to OpenLog without the component ID.
So I added the TaskJam script library, added it as resource and moved the application code in try…catch blocks. In the post are some suggestions to adapt the code in the library. Here are mine:
- Instead of view.getPageName() I used view.getRequestUrl() to get the full page name including parameters.
- for the logDbPath variable I re-used the same OpenLog reference in the XSP properties file (added as a resource bundle using path (“/WEB-INF/xsp.properties”) and call it by the variable name you provided e.g. var logDbPath = xspProp[“xsp.openlog.filepath”]
After writing some bad code I noticed the error registered in OpenLog. I am curious what errors will come in from Production for this application…
Happy development 🙂
Kwintessential Notes 