Community
Participate
Working Groups
Install/configuration routines should not depend on user's pre-existing PATH settings. - RHEL: SetConfig.sh depends on user's having "some" java in their PATH. build 20040804_1919 on Red Hat Linux Enterprise Linux 3.0 WS: Install with default destinaton creates AC bin directory with scripts RAStart.sh RAStop.sh SetConfig.sh SetConfig.sh calls `java` without providing a path for it. This depends on the user having some java in their path already. We shouldn't be dependent on "bring your own" java at this point. If the relative path from this script to an installed java IS affected by user's installation choices, then the call to java must be customized by the installer at install-time.
Hi Bing. I have transferred my bugs to you for triage. Thanks.
>>===== State: Assigned by:aernhart at 4/10/2008 5:24:10 PM ===== > Yes, prompting for the path would be an improvement, but given that > the installer already writes the path to the agent's java into > serviceconfig.xml, I think that it should write it into SetConfig also.. The installer itself is a Java program (SetConfig.java) which is invoked by SetConfig.sh(on Linux) or SetConfig.bat (on Windows). Currently it prompts user for the path of Java he wants to use for the Agent Controller. But to invoke it, we need a Java in the PATH or prompt user for it so we can start the installer. Assuming we are going to prompt user for the path of Java, we can't just assuming user wants to use the same JVM for the Agent Controller. We can use it as the default value though, i.e., user can just press 'Enter' to accept it. > It's ironic that SetConfig needs a java to launch a jar that then reads > the path to a java from serviceconfig.xml and displays it to the user. > Maybe SetConfig can also read serviceconfig.xml and use that java to launch the jar? In order for SetConfig to do this we need a JVM to invoke it. And the serviceconfig.xml packaged with Agent Controller does not contain path to Java until user runs SetConfig.bat or SetConfig.sh.
Commetns from user: ===== State: Assigned by:aernhart at 4/28/2008 12:45:47 PM ===== I think that I (and triage?) got the installers mixed up - RPT vs. TPTP and maybe this defect is in the wrong team: After I've used RPT Installation Manager (IM) to install RPT, serviceconfig.xml does have a path to the java that RPT or the Agent Controller just installed for RAServer's use. This path is correct for whatever drive and folder I told IM to install RPT into. From that I concluded that "the installer" does know where a good java is and should be able to update SetConfig.sh/bat to use that java to launch org.eclipse.tptp.platform.agentcontroller.config.SetConfig (even if that's not the java that the user chooses to have SetConfig write into serviceconfig.xml). But the TPTP product and SetConfig is apart from RPT and ships without a java and certainly without a location for the java. I think that IM calls another installer at least and think that IM or this other installer calls SetConfig.sh/bat to write serviceconfig.xml. One of these installers that knows the path to /opt/IBM/SDP70Shared/AgentController/jre/bin/java should fix up SetConfig.sh/bat to run without any prompting for a java. Even better: It seems that when RPT is installed by IM, there's no option to change the location of the AgentController's java and relative to the location of SetConfig.sh/bat, so SetConfig.sh/bat could have this: .../jre/bin/java SetConfig.sh runs fine with this and prompts with the full (not relative) path to that java when writing a new serviceconfig.xml file. That would be ideal for RPT. I don't know all the coordination that would be needed to do this though. => Prompting for a path is probably the best solution for TPTP, where a user is required to provide their own java and write a serviceconfig.xml file. For RPT, where the user is paying for more, and gets a java for it, we should provide an easier experience and have SetConfig.sh/bat just use that java without the user needing to look for it. Replacing "java" with the relative path to the AgentController java seems an easy way to do this and may be doable in the repositories rather than on-disk after installation.
Alan is right here. TPTP AC is not packaged with any JVM. If RPT installation includes JVM, then during installation, it could use the bundled JVM to invoked the SetConfig. Or at least modify the PATH to add the JVM or update SetConfig.sh/bat scripts where SetConfig.class is invoked.
No more actions are required on TPTP side. Closing for now.
closing
