SWT@Notes 8: Workbench startup and the Accounts API

So one of the things I have been wresteling with over the last couple of weeks is the Accounts API in Notes 8 / Expeditor. While very nice at the core it does leave something to be desired. Trying to interact with the Accounts API from a plugin running in Notes can and probably will result in an exception and the following messages being printed to the OSGi console if you happen to be looking there (which you really should). Look for an upcoming post for any easier approach… πŸ™‚

CLFMW0050E: Workbench is not ready to handle
   background thread request !
CLFMW0036E: Workbench is not ready for this
   operation

Suffice it to say that the lesson is that the Accounts API might be the same across Expeditor based clients but the implementation differs. For instance On Notes the accounts are stored in the local name and address book while it is stored in other formats in other Expeditor clients. This is all well and good but the fact that a Notes database is the backend store on Notes leaks through the API. The above messages are solved by running the code that access the Accounts API in a NotesJob. Really!? This is very poor design IMHO but something I think we have to live with.

Ahh the frustrations sometimes makes me want to scream…

Show ‘n Tell Thursday: Cross compiling sidebar plugins for Notes 8.0.x and Notes 8.5 (7 August 2008)


I haven’t done a SnTT in months (actually the last one was back on 24 May 2007) so I guess it’s about time. This week it’s about cross compiling sidebar plugins for Notes 8.5 and Notes 8.0.2. Enjoy…

Since installing Notes 8.5 I have had a lot of trouble developing in Eclipse 3.4 for Notes 8.5 and having the plugins work in Notes 8.0.x as well. The problem showed itself as a NullPointerException when trying to load the plugin Activator and a “Viewpart is null” message in the Notes UI. Looking at the log trace showed a class incompatibility message (“bad major version at offset=6”).

So far I have been screaming my lungs out, developing in Eclipse 3.4 and building the plugins in a virtual machine with Eclipse 3.2 as I couldn’t get plugins to work otherwise. Now I finally found a solution that lets me develop in Eclipse 3.4 and having the plugins work in Notes 8.0.x and Notes 8.5.

The issue is that Eclipse 3.4 configured with Notes 8.5 as a target platform is using Java 6 and that Notes 8.0.x is using Java 5 which causes class format problems. The solution is to set the required execution environment in Eclipse 3.4 which will cause Eclipse to build correctly. Setting the required execution environment (J2SE-1.5) is done in the “Overview”-tab of the MANIFEST.MF editor as shown below.

Using the GUI is of cause just a shorthand for editing the manifest manually. As an alternative you can edit your META-INF/MANIFEST.MF file directly and add the following line:

Bundle-RequiredExecutionEnvironment: J2SE-1.5

Please note that this is not the default value when creating new plugins in Eclipse 3.4 so you’ll have to pay attention and make sure it’s set correctly. This is of cause only necessary if your plugins need to work on Notes 8.0.x as well as Notes 8.5.

Thanks to Pierre Carlson from IBM for pointers on this.

Adaptors in Eclipse

A new article has been added to eclipse.org/articles and it describes the Adaptor pattern and how it’s used in Eclipse. A must read if you’re into Eclipse/Notes 8.x plug-in development. Below is the introduction.

“The adapter pattern is used extensively in Eclipse. The use of this pattern allows plug-ins to be loosely coupled, yet still be tightly integrated in the extremely dynamic Eclipse runtime environment. The adapter framework is used extensively by a wide variety of plug-ins, including those from the Eclipse platform, other Eclipse projects, and by the broader community and eco-system. The adapter framework should be considered as one of the essential parts of the Eclipse platform that everyone writing Eclipse plug-ins must know about.”

Article: Adapters

Didn’t know I could do that!

Didn’t know I could do that (don’t know whether it was added in Eclipse 3.4) but it sure makes it easier and faster to find the plugins you need to depend on. Instead of having to remember the entire name you can use the *-character. Sweet.

setlogrlev for Notes 8.5 from Eclipse 3.4

Using the Eclipse configuration I posted earlier the plug-in with the setlogrlev OSGi console command wouldn’t launch. To solve this you can either manually to start the com.ibm.rcp.core.logger plug-in from the OSGi console or configure the config.ini file on the launch configuration. The former can be done with the below command. A description on how to do the latter has been added to the step-by-step instructions.

start com.ibm.rcp.core.logger

Configure Eclipse 3.4 for Notes 8.5 plug-in development

So ever since I got one of the first drops of Notes 8.5 and with increasing effort since the public beta of Notes 8.5 came out I have been trying to get my Eclipse IDE ready for Notes 8.5 plug-in development no without success. Shout outs to IBM have been unsuccessful… πŸ™

Notes 8.5 is built on Expeditor 6.2 which in turn is based on Eclipse 3.4 (codenamed Ganymede). I couldn’t get my Eclipse 3.2/Expeditor 6.1 toolkit combo to work with Notes 8.5 and without an Expeditor toolkit for Expeditor 6.2 I couldn’t get my Eclipse 3.3/3.4 to work.

Finally today I managed to get my Eclipse IDE configured by piecing together different pieces of information found via Google. Below is a description on how to configure the latest build of Eclipse Ganymede (3.4 RC2) for Notes 8.5 plug-in development and debugging. Only caveat I have discovered so far is that I manually have to update the classpath for SWT libraries (e.g. org.eclipse.ui.swt) every time I restart Eclipse.

Once you have gone through the steps in the description (see link below) you should be able to run plug-in projects in Eclipse 3.4 using Notes 8.5.

Good luck!! πŸ™‚

Configure Eclipse 3.4 RC2 for Notes 8.5 public beta

SWT@Notes 8: Logging from SWT components

As you probably know using System.out.println for logging in Java is a no-no and this is also the case when developing plugins for Notes 8 and Lotus Expeditor. This post outlines how to use the logging framework supplied with Lotus Expeditor, how to manage the logging and where the logs go.

You have probably been using log4j or similar logging framework for years. Avoiding writing to System.out is even more important when writing SWT components and plug-ins for Notes 8 a.k.a. Eclipse since the output goes to a log tucked away under the covers. Luckily there’s an approach which is so much better and more flexible.

Logging basics

Luckily logging has been built into the language (since Java 1.4) and into the Lotus Expeditor platform. Actually there is 5 different frameworks built into the Lotus Expeditor platform. Based on advise from the Lotus and personal experience I really recommend you use the java.util.logging framework built into the core Java language. This is also known as JSR47 loggers. The below graphics shows the logging sub-system of Lotus Expeditor.



Page 8 from the
IBM Lotus Expeditor 6.1 Client for Desktop Serviceability – Logging and IBM Support Assistant (PDF).

As you can see from the above you can use the following logging frameworks in Lotus Expeditor:

  • Eclipse Logging
  • OSGi Logging
  • IBM Commons Logging
  • Apache Jakarta Commons Logging
  • java.util.logging a.k.a. JSR47

I haven’t got experience with all of the these frameworks and luckily I don’t have to. I just have to know about java.util.logging and there’s an abundance of info on that on Google. The Sun tutorial might be the best place to start if you’ve never used java.util.logging. All this being equal the frameworks work the same with the only difference being how you obtain loggers and what the different logging levels are called. Log levels are called something different in the different frameworks but slide 7 in the Lotus Expeditor documentation on logging shows the mapping between the different frameworks.

Using loggers in code

Using java.util.logging in code is really easy and consists of 3 steps:

  1. Obtain the logger to use (normally in a static final variable).
  2. Write info to the logger.

The below is an example of using loggers.

package com.example.logging;

import java.util.logging.Logger;

public class MyLoggingClass {
   // logger
   private final Logger log = Logger.getLogger(
      this.getClass().getPackage().getName());

   public MyLoggingClass() {
      log.finest("Finest...");
      log.finer("Finer...");
      log.fine("Fine...");
      log.info("Info...");
      log.warning("Warning...");
      log.severe("Severe...");
   }
}

The above code creates a logger in a variable called “log” as a private variable. The logger itself is called com.example.logging which is the name used to control the log level (see below). I find it best to name the logger after the package name that contains the class. Sometimes it is however beneficial to also have a logger with more specialized names to log info on specific events.

Configuring the logger log levels

The log level for a single logger or multiple loggers can be controlled using the LogManager using the <Notes data directory>/workspace/.config/rcpinstall.properties file. To change the log level for the com.example.logging logger to FINEST add the following line to the file and restart the client:

com.example.logging.level=FINEST

To change the level dynamically use the OSGi console commands as described below.

Interacting with loggers from the OSGi console

If you start the Notes 8 client with the OSGi console visible you can interact directly with the loggers using the console command called setlogrlev. To set the log level for the com.example.logging logger to FINEST use the following command:

setlogrlev com.example.logging FINEST

Please note that the logger levels are case sensitive so you have to write “FINEST” and not “finest”.

Where the logging goes

All log messages are written to log files in the <Notes data directory>/workspace/logs directory. Opening the directory will reveal a number of files. The two most important are error-log-X.xml and trace-log-X.xml. The file names are quite explanatory and are, as the extension implies, XML-files. When you open them they’ll be rendered using a XSLT stylesheet to be displayed nicely. You can either read them using a browser or using the “Help/Support/View Log” and “Help/Support/View Trace” menu item in the Notes 8 client.

While the log files are usable I personally find it much easier and better to use the OSGi console when developing as I can adjust the log levels on the fly.

Further reading