Using the IBM Connections API from other languages using custom certificates

I was reading up on some stuff in the IBM Connections REST API during the weekend and came across a post titled Using IBM Connections API in different programming languages on how to use the REST API from other languages than JavaScript from within IBM Connections. The approach there is very nice and quite valid but it fails to mention what to do if the SSL certificate of the API endpoint either isn’t trusted or isn’t certified using a “known” root certificate. In this case “known” means to the Java runtime you’re using or the runtime of any other language for that matter. Here I’m only dealing with Java though.

By default the classes will not allow a SSL connections to a server using a unknown/untrusted certificate but there are ways around that. Of course the best is always to make sure that the certificate of the server may be validated by the Java keystore (including intermediate certificates) but for testing – or if you know what you’re doing – simply ignoring the certificate test can be beneficial. Below is some code showing how to configure the SSL runtime to ignore the certificate and hostname checks. The code is a static configuration method and I deem it pretty readable. The code allows *all* certificates but could pretty easily be locked down to be more restrictive if need be.

private void enableSelfSignedCerts() throws Throwable {
  TrustManager[] trustAllCerts = new TrustManager[] {
    new X509TrustManager() {
        getAcceptedIssuers() {
        return null;
      public void checkClientTrusted(X509Certificate[] certs,
          String authType) {
      public void checkServerTrusted(X509Certificate[] certs,
        String authType) {

 SSLContext sc = SSLContext.getInstance("SSL");

  // Create all-trusting host name verifier
  HostnameVerifier allHostsValid = new HostnameVerifier() {
    public boolean verify(String hostname,
      SSLSession session) {
      return true;

  // Install the all-trusting host verifier



Joda Time comment

Ulrich Krause has an interesting post (Joda to the rescue) and I just had to comment on as I – probably to no surprise to many – work a lot with dates for the OnTime Suite. Ulrich is using the Joda Time library to compare two dates to see if they are on the same day by first stripping the time component which isn’t easily possible using java.util.Date. My comment is to remember that the Java Date object is just a wrapper about a UTC long so math can do the trick. Below is my comment.

While Joda Time is a great library there is an easier way to accomplish what you are trying to do. Simply remove the time component by doing a simple modulus calculation. I am not trying to be smart about it but we do this quite a lot at OnTime 🙂 Code could look like so:

Date d = new Date();
long lngTime = d.getTime();
lngTime -= lngTime % TimeUnit.DAYS.toMillis(1);
Date dNoTime = new Date(lngTime);

The latter date object creation isn’t actually necessary for the comparison. An utility function could be like so:

private boolean isSameDay(Date d1, Date d2) {
  long lngTime1 = d1.getTime();
  lngTime1 -= lngTime1 % TimeUnit.DAYS.toMillis(1);

  long lngTime2 = d2.getTime();
  lngTime2 -= lngTime2 % TimeUnit.DAYS.toMillis(1);

  return lngTime1 == lngTime2;

Hope it helps and it helps remove the dependency on Joda Time if that’s all you’re using it for.

Authenticating a web service request

In my current project I needed to place an authenticated web services request from Lotus Domino to an Oracle SOA endpoint. Turned out to be extremely easy using the Lotus Domino web services consumer feature as I just used the setCredentials(String, String) method which then adds the necessary Authorization header to the HTTP call. Below is an example.

MyEchoServiceLocator l = new MyEchoServiceLocator();
MyEcho u = l.getDomino();
u.setCredentials("Domino Admin", "password");
String result = u.echo("HelloWorld");
System.out.println("Result: " + result);

The Java native2ascii tool (also important for you XPages geeks)

To prepare for our upcoming trip to Tokyo I’ve been working on a Japanese translation of our OnTime Group Calendar 2011 client for Notes based on Java plugins. The internationalization engine (i18n) was already in place so it was merely a matter of doing the translation (thanks to Google Translate and friends) and then adding language files to our API. In that process one becomes very thankful of UTF-8 and the fact that Java works natively in UTF-8.

Please note that the approach discussed in this post translates (excuse the pun) directly to making translation files for XPages as well.

Using the Japanese translation the GUI looks like the below screen shot (cropped of course).

(click the image for a large version)

The funny thing about most non-Latin languages is that even though you have the translations it’s hard to impossible to write the characters yourself. And once you have the words getting them into the language files which are mere property files. Take the weekdays in Japanese as an example:


Because we’re running the OnTime Group Calendar out of Notes and because Notes is fully double-byte compatible we could actually just add the Japanese characters directly to the translation document. Instead however we opted to use the Java way that is the native2ascii tool.

The native2ascii tool is shipped with the JDK and lets you translate a file containing native characters to their UTF-8 equivalent escape sequences. So having my Japanese characters in japanese_source.txt and wanting to store the result in japanese_result.txt I simply ran the following command:

native2ascii -encoding UTF8 japanese_source.txt japanese_result.txt

The encoding parameter specifies the character encoding of the source file (here japanese_source.txt). The result is something like this:


Chose escape sequences go directly into the language property file and when read into a Java property file they are automatically translated into Japanese. Sweet!

SOAP Headers in Lotus Domino web service consumers and providers

In a current project we’re using the web service consumer and web server provider capability of Lotus Domino quite heavily. During the development the need to process the SOAP request headers which are provided in a section above the SOAP body. Problem is that these are not exposed through the proxy classes generated for you when you import the WSDL. Searching Google I came across the blog of Elena Neroslavskaya and more importantly the post that helped me out. Using the MessageContext class described in that blog post helped me crack the nut and now I can both iterate through the SOAP headers sent to me in the request and send SOAP headers back in the response. Sweet!

Below are two code snippets – one for iterating through request headers and one for sending headers back. Home it may help someone out there.

Iterate received headers

private void recurseHeaders(Iterator ite) {
  while (ite.hasNext()) {
    MessageElement elem = (MessageElement);
    String nsUri = elem.getNamespaceURI();
    String name = elem.getName();
    String value = elem.getValue();
    System.out.println("SOAP Header - ns , name , value ");

public com.example.FooResponseType foo(
  com.example.FooRequestType req) throws Exception {

  MessageContext mc = MessageContext.getCurrentContext();
  SOAPEnvelope envelope = mc.getRequestMessage()

Send back headers

import lotus.domino.axis.message.SOAPHeaderElement;
import lotus.domino.axis.message.MessageElement;

MessageElement elemGuid =
  new MessageElement("", "Guid");

MessageElement elemUser =
  new MessageElement("", "User");

SOAPHeaderElement elemHeader =
  new SOAPHeaderElement("", "TopElem");




OSGi, OSGi, OSGi – OSGi everywhere…

As mentioned in my OSGi presentation at AusLUG OSGi is a key technology for you if you dabble in IBM/Lotus products. Among other things it forms the basis for Lotus Expeditor (and therefore Notes, Sametime and Symphony), XPages and the XPages Extensibility Library. OSGi is now also part of Java application servers such as Websphere Application and the free and open source JBoss AS 7. The JBoss AS7 OSGi Full Presentation + Demo highlights OSGi in JBoss and has a nice introduction to OSGi. Highly recommended.

“JBoss AS7 (​as7) is a game-changer for both Java EE developers as well as application server administrators. And while JBoss is best known for being a Java EE container, in this session, we will focus on the OSGi capabilities of the new JBoss AS7. Starting with background information on OSGi in general, Thomas Diesler introduces the main objectives of this technology and explains the unique JBoss OSGi vision. Combining the best of two worlds we show how modern Java EE applications on AS7 can use the OSGi component model and vice versa.”

Knowledge path: RESTful web services

Found an excellent summary article on developerWorks called Knowledge Path: Build RESTful web services with Java technology. It has some very good information and links to articles split into 5 sections:

  1. Understand REST concepts
  2. Meet the Java API for RESTful Web Services (JAX-RS)
  3. Build RESTful applications with Java frameworks
  4. Combine REST with the Java Persistence API (JPA)
  5. Create RESTful web services with IBM WebSphere sMash

Great reads right there!

March Lotus Technical Information and Education (LTIE) community meeting

If you’re interested in plugin development and the recently published RedWiki on plugin development for Lotus Notes, Sametime and Symphony (easy url is be sure to join us for the March March Lotus Technical Information and Education (LTIE) community meeting. The conference call will be on 22 March at 10am Central Time (10am Eastern, 3pm CET).

For more info head over to the Lotus Technical Information and Education wiki on Lotus Greenhouse (look under “When we meet” at the bottom of the page).