Tag: java

As you probably know installing and uninstalling Java extensions (“plugins”) into the Lotus Notes client is easy using either File >> Application >> Install, File >> Application >> Application Management or the widget catalog. Sometimes however this doesn’t work and you’ll have to resort to a manual uninstall. This blog post outlines the way to perform a manual uninstall.

We have to start with some basics though. A Java extension in Lotus Notes (also known as a “plugin”) consists of two things:

1. Eclipse plugin(s)
   The plugin is where the actual code and functionality is stored together with additional resources such as images, string translation etc.
2. Eclipse feature
   The feature is what’s actually installed from a Lotus Notes perspective. The feature points to the Eclipse plugins that provides the actual functionality. It’s almso important to note that a single feature may reference multiple plugins.

Both an Eclipse plugin and an Eclipse feature are represented in the file system as JAR-files (files with an extension of “JAR”) and both of them are kept in the file system. A JAR-file is just a fancy ZIP-file with a predefined folder structure. Eclipse Features and plugins are stored in two directories beneath your Notes data directory (<Notes data dir.>/workspace/applications/eclipse/features for the features and <Notes data dir.>/workspace/applications/eclipse/plugins for the plugins).

From the above it may seem obvious that simply deleting these files will uninstall a Java extension – unfortunately there’s a final piece to the puzzle. Lotus Notes also keeps a record of what’s installed in a file called platform.xml (stored in <Notes data dir>workspace.configorg.eclipse.update). Simply deleting the feature(s) and plugin(s) may seem to work but will misbehave for instance when activating the File >> Application >> Application Management interface. The solution is to edit this file as well.

The complete steps to manually uninstalling a Java extension is therefore as follows:

1. Close Lotus Notes
2. Open the “features”-directory (<Notes data dir>workspaceapplicationseclipsefeatures)
3. Locate the Eclipse features to uninstall.
4. For each Eclipse feature you need to open it and edit the feature.xml file. Locate the <plugin>-tags and fine the names of the referenced plugins. Note that there might be more than one. Combining the plugin id and the plugin version will give the full filename of the plugin (<plugin id>_<plugin version>.jar).
5. Delete the Eclipse features you’re uninstalling.
6. Open the “plugins”-directory (<Notes data dir>workspaceapplicationseclipseplugins).
7. Delete the plugin JAR-file(s) you recorded in the step above.
8. Open the directory containing the platform.xml file (<Notes data dir>workspace.configorg.eclipse.update).
9. Edit platform.xml and go to the end of the file.
10. Remove each entry you see for the features you deleted in the step above.
11. Save and close the file.
12. Since Lotus Notes also keeps a record of which Java extensions to load it’s best to start Notes with some parameters to make it recompute the Java extension registry: notes.exe -RPARAMS -clean

Let me know if the above doesn’t work for you.

Please note: Manually uninstalling a Java extension installed via a widget descriptor via a widget catalog/policy will probably just make it reinstall once uninstalled.

If you’re developing console applications in Java that access Notes resources and you’re testing them in Eclipse you have experienced the following. You run your application to test it from Eclipse. It accesses a Notes resource and you haven’t granted 3rd party applications access in the Security settings so it causes Notes to ask you for the password – only the Console view doesn’t accept input… Bummer! 🙁

Fortunately there’s a solution to this which I’ll show below.

Disclaimer: I can in no way take credit for this tip as I didn’t discover it. The credit goes to Karsten Lehmann who posted it in the Design Partner forum.

The solution is not to make the password prompt go to the Console view but pop up a password entry dialog instead. The way to do this is to initialize the Swing UI framework before running your application as I do below (see code in bold).

import javax.swing.SwingUtilities;
import lotus.domino.Session;
import lotus.domino.Database;
import lotus.domino.DocumentCollection;
import lotus.domino.NotesFactory;
import lotus.domino.NotesThread;

public class Main {

  public static void main(String[] args) {
    try {
      SwingUtilities.invokeLater(new Runnable() {
        public void run() {}
      });

      NotesThread.sinitThread();
      s s = NotesFactory.creates();
      System.out.println("Name: " + s.getUserName());
      Database db = s.getDatabase("server1/Example", "names.nsf");
      DocumentCollection dc = db.getAllDocuments();
      System.out.println("Docs: " + dc.getCount());

    } catch (Throwable t) {
      t.printStackTrace();
    } finally {
      NotesThread.stermThread();
    }
  }
}

With the eminent release of Notes 8.5.1 it will become important for all you plugin guys and gals to update your configuration to work with Notes 8.5.1. This post will address this.

One of the really nice things about this new release is how Lotus strive to minimize the disk footprint of the install package. Part of this involves how jar-files are stored in the installed package but also how many Java VM’s ship with Notes. Previously there were 2 JVM’s – now there’s only one. There’s no longer a JRE stored in the plugin directory way down in the directory structure. Now you simply use the JVM in <Notes install dir>/jvm – simple right?!

This is nice but it means that your Eclipse configuration needs to be a little different JVM wise. I have therefore updated my Eclipse configuration guidelines to work with Notes 8.5.1.

Happy coding…

Please note: Once Notes 8.5.1 is final and released I’ll update the guidelines with the correct install id etc.