|Based on the testing we have done here, this problem does not appear to be due to ServletExec.
It appears to be a problem in how the JDK is setup by default after it has been installed on a Solaris OS.
Often the error message seen when this problem occurs looks something like this:
libmawt.so: open failed: No such file or directory
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
AWT makes native calls and it appears that the default installations of certain JDK/JRE implementations for Solaris (we've seen it with JDK 1.3.1) are not setup correctly to look for and use a required .so file named "libmawt.so"
There are a few different ways that you could setup your JDK so that it can find this necessary file. Here are some possible ways to do this, using JDK 1.3.1 (as an example):
The JDK wrapper script that is used to execute java, javac, jar, etc... may already have:
/jre/lib/sparc/ added to the LD_LIBRARY_PATH
Environment variable. If this is the case you could find the correct libmawt.so file for your version of Solaris and place a copy of it into that folder so that your JVM will always be able to find it.
On our Solaris 7 machine we found 2 libmawt.so files for our JDK 1.3.1 installation.
One was found at:
and the other was found at:
Our testing showed that Java code (running on the command line, not within ServletExec) which makes a simple AWT call such as:
Component test = new Frame();
would fail to run if we used the motif12/libmawt.so
But would run just fine if we used the motif21/libmawt.so
Another way to fix this so that your JDK installation will work with AWT code, would be to create a symbolic link in the
The name of the symbolic link would need to be libmawt.so and it should point to the actual libmawt.so file that is correct for your version of Solaris.
Suggestions #1 and #2 above may solve the problem for the entire
JDK on that machine. Which means it would not matter how you were using that JDK (from a command line, from an Application Server).
But if you just wanted to fix this so that your AWT code will only run correctly if run within an Application Server (such as ServletExec), then you may be able to adjust how the Application Server sets up the JVM before it invokes the JVM. How you do this would be application-server specific and even specific to how that application server is running.
For example, if you were running SE NSAPI on a Solaris OS, then if you wanted to you could edit the setting of the LD_LIBRARY_PATH Environment variable within the iPlanet server start script. You would want to include the folder that contains libmawt.so.
Of course this solution only solves the problem for when your AWT code is running inside that application server.
It would not fix the problem for cases when the JVM is started up in some other fashion (directly from a command line, or by some other application server for example).