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)
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.
2 comments:
sorry could have told you this, I must have missed the original post.
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 :-)
Post a Comment