Tuesday, 15 September 2009

Problems with 32-bit Lotus Forms Server API on 64-bit JVM

A few months back, I blogged about my experiences with Lotus Forms 3.5 and WebSphere Portal 6.1 together.

During that project, I hit a related problem whereby we were unable to get the sample portlets to render properly - we were attempting to render a portlet from a remote Webform server.

To cut a long and painful (!) story short, the problem was that we were trying ( unbeknown to me ) to run the Java APIs on a 64-bit JVM. Given that the Java byte code interacts with some native OS binaries, this was never going to work.

The key message ( in SystemOut.log ) was: -

Did not realize init() exception thrown by servlet Translator: java.lang.UnsatisfiedLinkError: pe_cc (/usr/lib/libpe_cc.so: wrong ELF class: ELFCLASS32.)
at java.lang.ClassLoader.loadLibraryWithPath(ClassLoader.java:981)
at java.lang.ClassLoader.loadLibraryWithClassLoader(ClassLoader.java:950)
at java.lang.System.loadLibrary(System.java:453)
at com.PureEdge.DTK.<clinit>(Unknown Source)
at java.lang.J9VMInternals.initializeImpl(Native Method)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:194)

This Technote: -

describes a similar symptom.

The solution - it's not possible to use the Lotus Forms Server products on a 64-bit JVM - this MAY change in a future release, but it ain't going to work in the short-term.


Keith Brooks said...

sorry could have told you this, I must have missed the original post.

Dave Hay said...

Yeah, I knew that 64-bitness wasn't an option - it just took me a wee while to work out that the client WAS using a 64-bit instance of Portal. I did all the other PD things beforehand, and this was the last thing I checked :-)

Grokking grep

A colleague was tinkering with grep  and, thanks to him, I discovered a bit more about the trusty little utility. I had not really explored ...