Hi all, this is my first posting here, and would most appreciate some
kind help.

I need to pass a string to the Linux shell from Java, and because of
the restrictions of the "getRuntime()" method, I'm trying to call up a
C program from Java to which is I passed a string.  The C program then
executes the "system()" function containing the string that I want to
pass to the Linux shell.  The idea eventually is to execute the code
as a bean in Glassfish, but I'm having trouble testing it out from the
CLI.  There seems to be some problem with packages and classpaths.
The code is in a file in a folder tree, the last two levels being "/
com/corejsf", and in the programs I have the declaration
"package.com.corejsf;"

There are four listings as follows:

// Listing 1
package com.corejsf;

import java.io.*;
import java.util.*;

class CallUserBean {
   public static void main(String[] args) {
       UserBean bean = new UserBean();
       String s = new String();
       s = "Passing this string to UserBean";
       System.out.println(s);
       bean.setName(s);
   }
}

Which calls the class in "UserBean.java"

// Listing 2
package com.corejsf;

import java.io.*;
import java.util.*;

public class UserBean {
   private String name;
   private String password;

// PROPERTY: name
   public String getName() { return name; }
   public void setName(String newValue) {
       System.out.println("Now in UserBean.setName()");
       System.out.println(newValue);
       String command = new String();
       command = "ls -lt > jnioutput.txt";
       System.out.println("Sending the string - " + command + " - to
native code");
       CallSystem.system(command);

       name = newValue;
   }

// PROPERTY: password
   public String getPassword() { return password; }
   public void setPassword(String newValue) { password = newValue; }
}

At the moment for the test only the methods "getName", "setPassword"
and "getPassword" are not used. This in turns calls the class in
"CallSystem.java":

Listing 3
package com.corejsf;

class CallSystem {
   public static native void system(String s);
   static {
       System.loadLibrary("CallSystem");
   }
}

Which calls the native C code in "CallSystem.c" ("UserBean.h" was
created with the "javah" command as required):

Listing 4
#include "UserBean.h"
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

JNIEXPORT void JNICALL Java_CallSystem_system(JNIEnv* env, jclass cl,
jstring jcommand) {
   const char *ccommand;

   ccommand = (*env)->GetStringUTFChars(env, jcommand, NULL);
   system(ccommand);

   (*env)->ReleaseStringUTFChars(env, jcommand, ccommand);
}

which passes a string to the shell for execution. In this case a
simple test "ls" is executed, as you can see in listing 1.

After I compile the C code and link in the shared library,
"libCallSystem.so", then compile the Java files with the "package
com.corejsf;" commented out in listings 1, 2 and 3, the code works
with the command:

"java -Djava.library.path=. CallUserBean"

from inside /com/corejsf and generates the test file "jnioutput.txt"
and write to it. This means that the native code is being called up
correctly.  However, if I uncomment the package statements and
recompile the Java files using the statements "javac -classpath
"../../" CallSystem.java", and likewise for the other two files then
issue the command:

"java -Djava.library.path=. -classpath ../../ CallUserBean"

the code in Java is executed correctly and generates the correct
output, but fails when it tries to call up the native code.  I get the
message:

Exception in thread "main" java.lang.UnsatisfiedLinkError:
com.corejsf.CallSystem.system(Ljava/lang/String;)V
       at com.corejsf.CallSystem.system(Native Method)
       at com.corejsf.UserBean.setName(UserBean.java:19)
       at CallUserBean.main(CallUserBean.java:11)

At best similar messages are obtained when I try other combinations of
"-Djava.library.path" and "-classpath", or the program doesn't even
get that far.  The fact that I can get it to work with the "package"
statements commented out means that it must be something to do with
the way the code is linked, and would be most grateful to have some
advice on this.

If this can be sorted out, the idea is to remove the code from listing
one, recompile listings 2 and 3, put them in a ".war" file, and put
the shared library in the appropriate folder for Glasssfish.  I have
in fact done this, and get the same error as above.

Christopher Sharp