K
K.Faw
I am working on a project that requires a java program running on a
Linux box to operate in different environments using different jar
files. Here is the flow:
1)java RMI app (call it jRMI) is running on linux box (started by
daemon). jRMI's remote method receives two strings strE and strJ -
strE is the name of a shell script file that sets the environment need
to execute a 2nd java program jTCPIP(to be defined below) and strE is
a jar file name to be used when executing jTCPIP.
2) Windows C++ app (call winApp) ultimately communicates with jTCPIP
via a socket opened by jTCPIP, but the environment jTCPIP executes in
and the jar file it uses can change. So, first winApp retrieves the
appropriate strE and strJ from a DB and calls jRMI's remote object
passing it these names.
3) jRMI's remote object receives strE and strJ and calls a script file
(myscript) passing it these two strings as arguments.
java code:
String bashCmd="bash " + "myscript " + strJ + " " strE;
Process proc=Runtime.getRuntime().exec(bashCmd);
4) the script file first executes the file specified by strE (sets
paths etc.) then it executes the jTCPIP program with the jar file
specified by strJ.
5)jTCPIP, once started, opens a socket and communication is
established between jTCPIP and winAPP.
winAPP----->(strE strJ)------>jRMI ()----->(strE,strJ)----
|-------->"java -classpath strJ jTCPIP" ---
|-------------------------------->( tcpip link between winApp and
jTCPIP)<-------------------------------------------------|
The problem I am seeing is that environments set by the execution of
strE script are not "seen" by jTCPIP (I can't think of a better word,
but ,for example, if JPATH is defined by an export statement in strE
("export JPATH=/home") jTCPIP does not know this definition).
I hope this explanation is clear enough. I can clarify any points as
needed, but I wanted to keep this as concise as possible. I'm looking
for a) advice on how to get jTCPIP to use environments set from
environment script strE OR b) recommendations on a better way to
implement this.
Linux box to operate in different environments using different jar
files. Here is the flow:
1)java RMI app (call it jRMI) is running on linux box (started by
daemon). jRMI's remote method receives two strings strE and strJ -
strE is the name of a shell script file that sets the environment need
to execute a 2nd java program jTCPIP(to be defined below) and strE is
a jar file name to be used when executing jTCPIP.
2) Windows C++ app (call winApp) ultimately communicates with jTCPIP
via a socket opened by jTCPIP, but the environment jTCPIP executes in
and the jar file it uses can change. So, first winApp retrieves the
appropriate strE and strJ from a DB and calls jRMI's remote object
passing it these names.
3) jRMI's remote object receives strE and strJ and calls a script file
(myscript) passing it these two strings as arguments.
java code:
String bashCmd="bash " + "myscript " + strJ + " " strE;
Process proc=Runtime.getRuntime().exec(bashCmd);
4) the script file first executes the file specified by strE (sets
paths etc.) then it executes the jTCPIP program with the jar file
specified by strJ.
5)jTCPIP, once started, opens a socket and communication is
established between jTCPIP and winAPP.
winAPP----->(strE strJ)------>jRMI ()----->(strE,strJ)----
|myscript-------->execute strE script (sets env)
|-------->"java -classpath strJ jTCPIP" ---
|-------------------------------->( tcpip link between winApp and
jTCPIP)<-------------------------------------------------|
The problem I am seeing is that environments set by the execution of
strE script are not "seen" by jTCPIP (I can't think of a better word,
but ,for example, if JPATH is defined by an export statement in strE
("export JPATH=/home") jTCPIP does not know this definition).
I hope this explanation is clear enough. I can clarify any points as
needed, but I wanted to keep this as concise as possible. I'm looking
for a) advice on how to get jTCPIP to use environments set from
environment script strE OR b) recommendations on a better way to
implement this.