lekkimworld.com - Java category

Actually showing the password prompt when developing Java for Notes

Tue, 02 Feb 2010 12:41:04 GMT

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();
    }
  }
}

Developing Java plugins and applications for Notes on 64 bit

Mon, 01 Feb 2010 11:56:10 GMT

I just upgraded my Thinkpad from Windows Vista 32 bit to Windows 7 64 bit and besides being amazed at the speed improvements (thanks to moving of Windows Vista) I needed to think about how I develop Java for Notes in general. When moving to 64 bits there are some things you need to consider if, and only if, you install the 64 bit version of the Java Development Kit (JDK) as I did. You need to consider stuff for two reasons which I'll address in turn.

Please note: This blog post will focus on 64 bits Windows 7 as that's what I'm running now but I suspect it will apply to other Notes platforms such as Windows Vista, Linux and Mac as well. I'm not using Lotus Expeditor Toolkit so I can't confirm the following is but a wise man told me that XPD Toolkit doesn't support 64 bit JDK's so in that case you need this as well as my "Configure Eclipse 3.4 for Notes 8.5.1"-guide as well.

Notes is a 32 bit application

Say you install a 64 bit JDK and try to run an application that access Notes using local address (NRPC; a client or server installed on the same machine) such as the following:

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) {
      NotesThread.sinitThread();
      Session s = NotesFactory.createSession();
      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();
    }
  }
}

The code will compile fine but when you run it you'll see a message like the following (plus a stacktrace):

java.lang.UnsatisfiedLinkError: C:\Notes8\nlsxbe.dll: 
   Can't load IA 32-bit .dll on a AMD 64-bit platform

The problem is, as the message explains, that you cannot load a 32 bit DLL (remember Notes is a 32 bit application) into a 64 bit Java Virtual Machine (JVM). The solution is to install a 32 bit JDK instead and run the application using this JDK. Remember that it is perfectly valid and possible to install multiple JDK's on a single machine and it fact that's what I'm doing.

Developing plugins for Notes 8+

Developing plugins for Notes 8+ on 64 bit Windows is also somewhat different from doing it on a 32 bit Windows system. Of course you need Eclipse but here's the first difference - you need to use a 64 bit version of Eclipse if you're using a 64 bit JDK. The reason is that Eclipse uses SWT (Standard Widget Toolkit) for the user interface widgets. The reason SWT looks so nice on any supported platform is because it wraps the native, C-code, platform widgets. So remember that and grab a 64 bit Eclipse. Once that's installed and working with your 64 bit JDK configure Eclipse as you normally would but with a small difference that will cause your code not to compile (my Eclipse complained about not be able to resolve org.eclipse.swt.widgets.Shell).

As you may know, you specify the bundles you depend on when developing your plugin and in turn you also specify which environment you run in. This is how Eclipse knows which versions to the bundles to put on the class path but since you're running 64 bit Windows and Notes is 32 bits it will be a problem. The fix is however very easy to implement and only means tweaking the target platform setup to explicitly set the architecture you're running on to "x86" and not "x86_64" which is the default if you're on a 64 bit JVM. Where to set this differs a little between Eclipse 3.4 and Eclipse 3.5 but the concept is the same.

Open the target platform setup
Edit the "Environment" settings
Set the architecture to "x86"

Once this is done the workspace will be rebuilt and everything should work just fine. Mine did anyway... :-)

Back to our standalone Java application

If you need to run a Java application that accesses Notes locally from within an Eclipse instance (lets face it - who writes Java code without an IDE these days?) you also need to use a 32 bit JVM although you very well may be running 64 bit Eclipse in a 64 bit JVM. The JVM used to execute an application from within Eclipse is the JVM you setup in the build path. To set it simply right-click the project, choose Build Path -< Configure Build Path... and replace/edit the JVM library used.

Conclusion

I hope the above is clear - if not let me know using the comment system. I'll soon be blogging about using Eclipse 3.5 for your Eclipse development instead of the current version 3.4. Stay tuned.

Signed demo plugin on OpenNTF

Wed, 11 Nov 2009 09:34:53 GMT

Today Niklas Heidloff tweeted about a new demo Java extension that have been published on OpenNTF. Besides being a very nice demo example it also has another noticeable difference from all other Java extensions that have been published so far. The difference is small although very important. The difference is that it's digitally signed!

When installing Java extensions in Notes you have probably grown used to the "Are you really, really, really, really sure you want to install this unsigned Java extension in your Notes client"-prompt. Without thinking you probably click "Yes" out of habit which is why you may not remember the prompt. If you install this Java extension you wont see this prompt because it's signed by a certificate you trust (it's an IBM certificate).

Using jarsigner -verify -verbose -certs on the feature will yield something like this:

[entry was signed on 01-11-09 04:05]
X.509, CN=International Business Machines Corporation, 
OU=Lotus Software Group, OU=Digital ID Class 3 - Java 
Object Signing, O=International Business Machines 
Corporation, L=Westford, ST=Massachusetts, C=US

The difference is small but very important. You did notice it didn't prompt you right?

Configure Eclipse 3.4 for Notes 8.5.1

Wed, 30 Sep 2009 10:42:08 GMT

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.

Domino Server Extensions: RunJava or Eclipse Plugins? - PLEASE GO VOTE!!

Tue, 04 Aug 2009 05:52:00 GMT

A little while back I mentioned that Bob Balfe was inquiring about Domino server extensions in Java and whether it was of interest to us as developers (JavaAPI for Servertasks - Documented and Supported). Interesting? Are you kidding me? It would be VERY interesting.

Now Bob in his blog post "Domino Server Extensions: RunJava or Eclipse Plugins?" is asking which extension mechanism we would prefer so PLEASE GO VOTE! This is really important and would make the Domino server much more approachable and much easier extensible.

Custom plug-in builds in Eclipse

Wed, 01 Jul 2009 21:13:46 GMT

Just had an interesting issue where I needed to make sure my Eclipse plug-in had the latest version of a jar-file I build in another Java project. Normally including a jar-file in a plug-in project is easy enough but when doing that you're normally using a static jar-file that doesn't change. I needed my plug-in to use the latest jar from the other Java project whenever the plug-in was built. Hmmm....

After some searching around and some hints via Twitter I found the solution and it was very easy as Eclipse already include the plumbing for this (from Eclipse 3.2). The solution was to contribute custom build steps to the build.xml that the PDE in Eclipse auto-generates. It's way easier than it sounds.

The only changes I needed to make to my plug-in project was to:

Add "customBuildCallbacks=customBuildCallbacks.xml" to the build.properties
Add a customBuildCallbacks.xml Ant file to my plug-in project (the one that needed the newest jar) with a single target called "pre.gather.bin.parts"
Write "code" for the target that replaces the jar-file in my plug-in project with the one from my Java project
Build the plug-in via my update site

For full details refer to Plug-in Development Environment Guide/Tasks/PDE Build Advanced Topics/Feature and Plug-in custom build steps in the online help.

Generating unique id's for Notes widgets

Sun, 21 Jun 2009 08:39:40 GMT

If you write code to automatically generate widget descriptors (aka extension.xml) for users you have to ensure that the widget id is unique. A nice exxample of this can be found here. One caveat is that the widget id is used to distinguish the widgets hence has to be unique. To easiest way to generate a unique id in Java is to use the java.util.UUID class. Generating a unique, random, id with this class is easy.

String id = java.util.UUID.randomUUID().toString();

Don't install Notes in the default location if doing Notes plug-in development

Wed, 17 Jun 2009 13:07:58 GMT

A little while back I was contacted by a fellow Yellow-head who had some issues with some plug-in development for Notes 8. Unfortunately I wasn't able to help him at the time but when he some head scratching time later found the answer he was kind enough to share it. I thought I would share it here in case it can help someone.

From the offset the issue looked simple as it had to do with the good old nlsxbe which is normally caused by the binary Notes directory not being on the path. The issue was however a bit twisted as the error raised complained about the filename or extension being too long.

java.lang.UnsatisfiedLinkError: nlsxbe 
   (The filename or extension is too long. )

What our good Yellow-head found out was that the issue was caused by his install location of the Notes client. Specifically he had installed his client in "C:\Archivos de programa\IBM\Lotus\Notes" which is the default location for his OS. This however means that the path to the notes.jar for plug-ins becomes "C:\Archivos de programa\IBM\Lotus\Notes\framework\rcp\eclipse\plugins\com.ibm.rcp.j2se.win32.x86_1.5.0.SR4-200707311521\jre\lib\Notes.jar" which is too long a path (longer than 128 characters). Installing Notes in "C:\program files\IBM\Lotus\Notes" solved the issue.

So if you run into weird issues like this check your install path or choose an English copy of Windows! :-)