Month: March 2006

Loving policies – especially mail settings


Starting with Domino 7 the policy document has six fields to policy setting document. The sixth settings document called mail settings was introduced in the Domino 7 release and allows you to control many of the mail and calendar settings of your users centrally.

The sweet thing is that only the server, and hence the Domino Directory, needs to be on release 7 for you to exploit this functionality.

The below text is excerpted from “Creating a mail policy settings document” in the Domino 7 Administration help file:

"The effective mail policy for a user is stored in that user's mail database in the calendar profile. The administration process writes the mail policy to the calendar profile. The administration process checks for mail policy updates every 12 hours, and when necessary updates the user mail files according to the changes in the mail policy settings document."

As stated it is the administration process that applies the settings so it doesn’t matter that you have a mixed environment of Notes client versions. I have succesfully used this approach in a combined 6.x, 6.5.x, 7.x customer environment.

It can be a real timesaver if you need to deploy common calendar alarm settings, letterheads etc. across your organization. The settings will even be applied even though the user doesn’t log on.

Re: How are roaming id-files encrypted?

Well the message from Lotus Support on the roaming id-file question (see the original post “How are roaming id-files encrypted?” for the whole story) is that no one seems to know. The technician in charge of my PMR called me and it seems like none of the people, including the support guys in Ireland, knows what’s up with the “double encryption”. He did however say that he got in contact with a developer in Germany via IM who would take a look at the actual Notes/Domino code on Friday.

The technician from Lotus Support would get back to me on Friday or Monday so we’ll see what happens. Lets just hope the answer isn’t hard to come by because it is security by obscurity…

Show ‘n Tell Thursday: Setting the Content-type from a Java agent (30 Mar 2006)


Suppose you are all into this new AJAX thing and you need to output XML from your agent. If you write the agent in LotusScript you simply output the Content-type header using a Print statement as the first output to the browser.

Print "Content-type: text/xml"

Setting the Content-type from a Java agent however seems to drive many people crazy. They seem to set the Content-type header correctly but it fails to manifest itself in the browser (the XML comes out wrapped in Domino HTML). This happens since they fail to understand what they actually need to do. The Content-type needs to go on its own line hence you need to insert a linebreak after the Content-type as the below example shows.

import lotus.domino.*;

public class JavaAgent extends AgentBase {

  public void NotesMain() {

    try {
      Session session = getSession();
      AgentContext agentContext = session.getAgentContext();

      java.io.PrintWriter pw = this.getAgentOutput();
      pw.println("Content-type: text/xml");
      pw.println("<?xml version="1.0" ?>");
      pw.println("<names>");
      pw.println("<name first="Mikkel" last="Heisterberg" />");
      pw.println("</names>");

    } catch(Exception e) {
      e.printStackTrace();
    }
  }
}

The key (highlighted in bold above) is to use the println()-method of the java.io.PrintWriter instead of simply the print()-method or the write()-method.

I said it wouldn’t be a long post…

Re: Is the lack of Java skills in the Notes/Domino developer community the Achilles’ heel of IBM?

First of all, there is no doubt that the followers of the Notes/Domino platform are very passionate about the platform, where it is and where it is going. This is a good thing. We saw evidence of this at Lotusphere as well. That being said I think that the discussion in the thread on Eds blog has probably ventured somewhat off-topic into a discussion on development platforms and a discussion on strongly vs. loosely typed programming languages. Probably a discussion best left in another forum… 🙂

Worse though is the fact that some just refuse to accept the change that is inevitable in this industry. The move to Java, or another new programming language, in the future is inevitable. However no one, certainly not myself, dispute the fact that LotusScript is the de facto programming language of the Notes/Domino platform. We all know IBM makes mistakes once in a while but I certainly do not think they would saw of the branch they are sitting on by deprecating the LotusScript language. As I wrote in the original post: “LotusScript will probably be supported from now to the demise of the platform.”

I think Ed explains it very well and clearly in one of his comments (@61) to the discussion thread:

"So yes, the userbase wants to keep Lotuscript as the default language. And to be clear, Lotuscript doesn't go away, change, or deprecate in the Notes "Hannover" release. And some of the ideas here on how to extend the value of a Lotuscript skillset are interesting and make sense. But a view of the larger IT market indicates that the need to incorporate other languages -- AND development tools -- with the Notes environment of today is an even better bet."

Please note here that not deprecating LotusScript is in no way the same as extending it and having the LotusScript API provide the same level of functionality that I think the Java and JavaScript API will provide in the Hannover+ timeframe. LotusScript will survive as a Notes/Domino language but Java and JavaScript will, even though adoption seems to be painfully slow, become the new Lingua franca of the IBM World.

We, as the ever-passionate Notes/Domino community, have to overcome our fear of change and accept that application development has, and continues to move away, from the proprietary, all-in-one-NSF, single-platform development style that has been prevalent for so many years. This doesn’t mean that you have to move away from this type of development and a lot of applications will continue to benefit from the RAD (oops – I said it!) environment of Notes/Domino.

It is just that the majority of new applications being developed, or existing ones getting a tune-up, needs to look outside the Notes/Domino platform for information. Whether this be a simple lookup in a RDBMS, a call to a web service or a series of complicated calls to an ERP system doesn’t really matter. The can of worms is open and to think that the complexities of system integration will disappear in the foreseeable future is just mad. Having a non-proprietary programming language with widespread industry adoption makes this kind of system integration a lot easier and the benefits should be clear. For one we can avoid the proliferance of custom LSX modules wrapping C/C++ API code to provide access to system X, Y and Z.

The shift towards composite applications, including the kind you can build in Hannover, will be all about system integration – this is why Java adoption is a necessity. Not for the traditional kind of applications but for the new stuff.

Instead of bitching and moaning I think we, as a community, should be thrilled and instead focus on the fact that IBM has seen this shift coming, and that Notes/Domino with the Hannover client is embracing the future and providing the tooling to leverage existing investments in other platforms. Lets embrace the future not hide away from it refusing to accept the change that is coming.

The need as a developer to skill-up by embracing Java might seem unjust and a burden but the alternative would be even worse. You, and the customer you serve (whether the customer be internal or external), would be left behind with a dead, proprietary, used-to-be-great platform. Instead you are getting a heads-up while there is time.

Happy coding… 🙂

FeedDemon 2.0 released

FeedDemon, the feed reader by Nick Bradbury, has been released in version 2.0. I have been using FeedDemon for my feed reading since its inception and I can totally vouch for it. A cheap, state-of-the-art feed reader with a built-in podcasting client. So it you’re looking to try something new, or just need a killer feed reader I would definately recommend that you check it out.

Does personal notes.ini settings roam?

According to a technote on www.lotus.com/support (“What Notes.ini values are stored and replicated in the Personal Address Book for a Roaming User?”) not all settings roam – I paid special mention to the fact that personal notes.ini settings, that is those that start with $-sign, doesn’t.

I called Lotus Support to verify that this is in fact correct since it could be considered a real issue since many applications use these personal notes.ini settings as part of the application. Not having these settings roam could really impact application perception by users. Here is the response I got from Lotus Support:

"PMR xxxxx,xxx,xxx is about the notes.ini parameter question an[d] the answer is no, but there is an enhancement request for this. Unfortunately this will not be fixed in R6. Would you like me to add your name to the list of customers who would like this to be fixed in R7?"

So I’m afraid the technote is correct. A SPR (Software Problem Report) for this was opened against R6 (SPR# DPAT4WSLVK) but it was decided that it wouldn’t be considered for the R6 codestream. I opened a SPR for the same issue against the R7 codestream. For those who want to add their voice to the SPR number is DPAT4WSLVK.

Managing external Java dependencies in Domino Designer

Please note: Lotus Notes/Domino will ignore the CLASSPATH variable set on the local machine. Likewise Notes/Domino doesn’t use Manifest files in jar-files.


One of the major advantages of developing in Java is the abundance of high quality open source libraries available to help you dramastically cut development time. Apache Jakarta and OpenSymphony are just two examples of sites that hosts high quality components you can leverage in your day-to-day developments (make sure to look into Jakarta Commons). The libraries are most often distributed in the form of one or multiple JAR files that you need link to when developing and compiling your code.

If you are unfamiliar with JAR files they are bascially ZIP files with a special directory structure. They are used to package compiled classes and let you handle one file instead of a whole directory tree. Much easier. For more information on JAR files refer to the page Packaging Programs in JAR Files at java.sun.com.

With external dependencies come complexity and issues as to where to place the JAR files so Domino Designer, the Notes client and the Domino server can find the code at design and runtime. When having external dependencies you basically have four options:

  • Include the classes in the agent/web service you are writing.
  • Put the classes in a Java script library and include the script library.
  • Use the JavaUserClasses notes.ini setting.
  • Put the classes in the jvm/lib/ext folder.

Below I’ll explain a little about each approach.

Include the classes in the agent/web service you are writing

This means using the “Edit Project” button in the Domino Designer Java IDE to include JAR files from the local file system in the agent/web service itself. This approach is valid and very easy to use but can mean dublicating the classes across multiple agents/web services in the same database. It is perfect for not having any dependencies outside the database.

Put the classes in a Java script library and include the script library

This means importing the JAR file(s) into a Java script library and then including the script library from agents/web services. This approach is for most cases the preferred way of using JAR files with Domino Designer since you avoid dublicating the code across design elements while avoiding dependencies outside the database. It also means that the code is easily shared among developers working on different agents concurrently.

Use the JavaUserClasses notes.ini setting

The JavaUserClasses notes.ini setting is the equivalent of the CLASSPATH setting used when developing in Java outside Notes. The setting makes the classes universally available so you can use them just like the classes from the java.*-packages lotus.domino.*-package. The setting is restricted in length (due to the limits imposed on notes.ini settings) and isn’t sharable across clients.

Put the classes in the jvm/lib/ext folder

Putting external JAR files in the jvm/lib/ext folder under your binary Notes directory affords you the same universal availability of the classes as the JavaUserClasses setting but without having to manually edit the notes.ini file. This possibility was introduced with Notes 6. Putting the classes in the jvm/lib/ext folder has some additional advantages when it comes to security but that’s for another post.

The table below shows the applicability of the different approaches.

td.center {
text-align: center;
}

Designer Notes Domino Replication Sharable Agent Web service Servlet
Include in agent + + + + – + – –
Include in web service + + + + – – + –
Script library + + + + + + + –
JavaUserClasses + + + – + + + +
jvm/lib/ext + + + – + + + +

As the table shows it is important to note that the JavaUserClasses and jvm/lib/ext approach are specific to the local machine that is it doesn’t replicate. This means that all installations (clients and servers) must maintain the setting manually. This can really be a hassle and doesn’t lend itself for use in applications deployed to end users. The approaches are very usable for servers though.

The table also shows that classes imported into a specific agent are not sharable that is you have to import the JAR file in every agent that uses the classes thus you have to remember updating the JAR file in every agent if upgradering to a new version of the JAR file. It can be a strength though if different versions are required. I recommend avoiding this approach whenever possible. Use script libraries instead.

Finally only the JavaUserClasses and jvm/lib/ext approaches can be used to load classes for servlets running under the Domino servlet manager.

Conclusion

In conclusion you should pay attention to what you are trying to accomplish when choosing the location for the JAR files you depend on. Each approach has its strengths and weeknesses.

For most cases the preferred way is using Java script libraries.

Improving Domino 7 and DB2 Performance

In this post on LDD John D Curtis links to a new piece of Domino 7 documentation titled “Improving Domino 7 and DB2 Performance”.

“Improving IBM® Lotus® Domino® and DB2® Performance contains information to help you optimize the performance of your DB2 server running in a Domino and DB2 configuration. . The information in this document is intended for configurations that utilize medium size servers because the parameters are tuned for medium size server systems. Other hardware configurations may require additional adjustments.”

The documentation database can be found on LDD in the Technical Library (scroll down to the bottom).

Domingo – a fresh start for the Notes/Domino Java developer community?

Domingo is an open source project hosted on Sourceforge that builds upon the standard Lotus Notes/Domino Java API. The Domingo website describes the project as follows:

Domingo is a simple, consistent, object-oriented easy-to-use interface to the Lotus Notes/Domino Java-API.

The project promises easier coding and no more manual recycling of objects.

It is still early in the lifecycle of the project so there is no real documentation up yet except for a small example. The Javadoc is available through and the source code can be viewed on Sourceforge.

I haven’t really looked into the project in great depths yet, but it is nice to see someone investing the time to build a more modern and up-to-date API for Java. It looks like the framework wraps the entire Notes/Domino Java API though it isn’t a drop-in replacement which is too bad since I think it will be a major barrier for adoption.

It’s going to be fun and follow this project.